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1.  Introduction 


Tbis  is  the  Final  Repoit  £w  Phase  One  of  the  BBN  Labonuohes  Knowledge  Acquisition  Project  This  research 
was  supported  by  the  Defense  Advanced  Research  Projects  Agency  of  the  Department  of  Defense  and  was 
monitored  by  the  Rome  Air  Developmem  Center  (RADC)  under  conctaa  number  F30602-8S-C-000S. 

The  goal  of  this  project  was  to  create  a  useable  and  extensiUe  knowletige  engineering  environment  that  will 
be  capable  of  handling  very  large  knowledge  bases,  support  experiments  with  knowledge  engineehng  techniques 
and  implemeis  a  useable  system  for  knowledge  acquisitioa  arxl  maintenance.  During  Phase  One  of  this  projea  we 
have  created  the  KREME  Knowledge  Representation  Editing  and  Modeling  Ertvironment  KREME  is  an  extensible 
experimental  envirotmeta  for  developing  and  editing  large  knowledge  bases  in  a  variety  of  representation  styles.  It 
provides  tools  for  effective  viewing  and  browsing  in  each  iHnri  of  lepreseotation.  automatic  consistency  checking, 
macro-editing  fadliries  to  reduce  the  burdens  of  large  scale  knowledge  base  revision  and  some  experimental 
automatic  generalizatioa  and  acquisitioa  facilities. 

Among  the  planned  extensions  to  KREME  are: 

•  The  Procedure  Editor 

•  A  KEE  Interface 

•  The  Addition  of  Boolean  Connectives  to  Slot  Restrictions 

•  Extension  of  the  Macro  Editor 

We  are  cutrendy  in  the  process  of  extending  the  value  restriction  language  to  permit  more  complex  forms 
contairting  conjunctious.  disianctiom  and  negations,  based  on  the  restxiciion  language  for  KEE**"'  hames  [6].  This 
effort  should  result  in  an  extended  classifier,  as  well,  capable  of  mataaining  consistency  among  frames  in  the  KEE 
class  of  frame  languages. 

During  Phase  Two  we  will  also  be  developing  experimental  kinds  of  automatic  knowledge  acquisition: 
tecfaniqoes  frrr  geneming  controlled  acquisitioo  dialogues,  procedures  to  automatically  transfonn  previously 
acquired  knowledge  for  use  in  new  tasks,  and  techniques  for  leamiog  by  analost  and  from  examples. 

The  appendixes  to  this  manual  provide  the  detailed  iafiwmmion  needed  by  those  who  will  be  installing  and 
using  KREME  at  their  sites.  Appendix  A  provides  instntctions  a  loadng  KREME  from  tape.  Appendix  B  is  a 
User’s  Innoductioo  to  KREME.  Appendix  C  presents  a  sample  KREME  sessioa 

THIS  MATERIAL  MAT  BE  REPRODUCED  BY  OR  FOR  THE  U.S.  GOVERNMENT  PURSUANT 
TO  THE  COPYRIGHT  LICENSE  UNDER  THE  CLAUSE  AT  52.227-7013  (MAY  1981). 
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2.  Overview  of  the  BBN  Knowledge  Acquisition  Project 


Ossr  goal  has  been  to  develop  an  envinxment  in  which  the  problems  of  knowledge  acquisition  fiiced  by  every 
knowledge  engineer  attempting  to  build  a  large  expert  sysmm  are  minimiTed,  We  believe  both  knowledge  engineers 
and  snbjea  matter  experts  with  some  knowledge  of  basic  knowledge  tepteseixaiion  techniques  wiU  find  it  easy  to 
use  KREME  to  acqnite,  edit,  and  view  from  multiple  perspectives  knowledge  bases  that  are  several  times  larger 
(Le.,  3-10,000  concepts)  than  those  fbond  in  most  current  systems. 

KREME  attempts  to  deal  with  the  inextricably  related  problents  of  knowledge  reptesentatioo  and  knowledge 
acquisitioo  in  a  imitwH  manner  by  organizing  multiple  rqtresetttation  languages  and  multiple  knowledge  editors 
inside  of  a  cobetertt  global  envuonment.  A  key  design  goal  for  KREME  was  to  build  an  envirooment  in  which 
existing  knowledge  tepteseotadon  languages,  appropriate  to  diverse  types  of  knowledge,  could  be  integrated  and 
organized  as  components  of  a  cobetertt  ^obal  leptesemaiioo  system.  The  current  KREME  Knowledge  Editor  can 
be  thought  of  as  an  extensible  set  of  globally  coherent  operations  that  apply  across  a  number  of  related  knowledge 
repiesetttation  editoia,  each  tailoied  to  a  specific  type  of  kixmledge.  Our  approach  has  been  to  integrate  existing 
frame  and  rule  repnsetttation  languages  in  an  open  ended  architecture  that  allows  the  extension  of  each  of  these 
languages.  In  addition,  we  have  provided  for  the  incorporation  of  addiiiooal  tepreseniatton  languages  to  handle 
additional  types  of  knowledge. 

Our  approach  to  consistency  maintmance  has  been  to  develop  a  knowledge  inugration  subsystem  that 
includes  an  antomatie  fran%e  class^ier  and  fitcilities  for  inter-language  consistency  mainienaiKe.  The  frame 
classifier  antomatically  maintaim  logical  consistency  among  aU  of  the  fiames  or  conceptual  dass  definidons  in  a 
KREME  frame  base.  In  addtdon,  it  can  discover  implicit  class  reiadoosb^  since  it  wiU  determine  when  one 
definition  is  logically  subsumed  by  another,  even  when  the  ktwwiedge  gnginii^  has  not  explicitly  stated  that 
leladonsfaip.  The  imer-language  consistency  maintenance  fmility  checks  for  inconsistencies  in  references  to  frames 
in  knowledge  bases  specified  using  other  teptesetttadoo  languages  (e.g.,  rules,  procedures). 

A  second  important  atea  of  invesdgadon  in  developing  the  KREME  editing  environmettt  has  been  the  attempt 
to  provide  fodfides  for  large-scaie  tevisiaos  of  a  knowledge  base.  Our  experience  mdicaies  that  the  development  of 
an  expert  system  inevitably  lequnes  such  systematic  revisions  of  the  developed  repiesentadoa  This  is  often  caused 
by  the  addMon  or  ledefinidon  of  a  tarit  the  system  is  to  petfnm.  These  land«  of  systematic  changes  to  a  knowledge 
besa  generally  tetprim  piinstalrinf  pjecemeal  revision  of  each  affected  elemeot.  one  a  a  time.  Our  initial  ai^xoacfa 
has  been  to  provide  s  macnhedUng  fKfiky,  in  whacfa  the  requited  editing  operations  can  be  demonstrated  by 
exampia  and  apfdied  to  specified  sets  of  knowledge  structures  antomatically.  A  library  of  genetic  macnxditing 
openttions  for  the  most  common  and  conoepmally  siinple  (though  potentially  difficult  to  describe)  operatioos  will  be 
developed  duinf  Phase  Tsvo  of  the  project 

FInaily,  we  have  began  to  inveadgaK  techniques  Cor  automatic  generalization  of  concepts  defined  in  a 
knowledge  base.  We  will  briefly  deecrfoe  these  experimeitts  as  wril,  in  Section  8. 
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Uodeilying  tlie  emiie  KREME  system  is  a  snoag  notioa  of  meta>Ievel  knowledge  about  knowledge 
iqueseotadoo  and  knowledge  acquisitioa  The  repiesentatioo  tangna^  weie  implemented  based  on  a  careful 
decomposition  of  existing  knowledge  representatioa  tecfaniques  and  implemented  as  combinable  objects  using 
FLAVORS  [7].  By  oiganizing  tUs  meta-level  knowledge  base  modulaily.  behavioral  objects  implemenring  such 
noiioiiB  as  inheritance  and  subsnmpiioa  could  be  "mixed  in"  to  a  variety  of  representational  subsystems  making  the 
incotpoiaiion  of  new  representations  and  their  editois  reasonably  straightforward.  That  is.  each  objea  in  the 
meta-knowledge  base  encodes  some  aspect  of  a  traditional  representational  technique,  and  is  responsible  for  its  own 
display,  editing  and  internal  forms. 


3.  The  KREME  Knowledge  Representation  Editing  and  Modeling 
Environment 


Functional  Description 

The  KREME  &unity  of  knowledge  editofs  cuiientiy  consists  of  thiee  major  editor  modules:  a  frame  editor,  a 
rale  editor,  and  a  procedure  editor.^  (See  figure  3-1.)  KREME  also  includes  a  large  toolbox  of  editing  techniques 
that  are  shared  among  the  editor  modules.  Hus  secdon  will  describe  the  global  environment  and  toolbox,  later 
sectioos  will  describe  the  individual  editors.  Sections  3  J  through  3.5  provide  a  discussion  of  the  user  interface. 
Readen  who  require  more  detail  should  consult  Appendix  B. 


Flftire  3>1:  KREME:  Rmcrional  Desctiptioo 
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3.2  Basic  Editing  Environment 


Each  type  of  represeotadoo  included  in  the  system  has  defined  fm  it  one  or  more  editor  views.  A  view  is  a 
coUectioo  of  windows  appearing  together  on  the  screen.  Each  window  displays  some  aspect  of  the  paidcolar  piece 
of  knowledge  being  edited  and/or  a  set  of  editing  operations  on  it.  When  the  user  desires  to  enter  or  edit  a  specific 
piece  of  knowledge,  the  system  opens  the  most  appropriate  view  fev  the  type  of  knowledge  and  the  editing  operation 
requested.  Typically,  aoy  aspect  of  the  knowledge  being  edited  can  be  changed  or  viewed  in  more  detail  simply  by 
pointing  at  it.  This  organization  allows  knowledge  to  be  viewed  by  the  user  from  multiple  perspectives  and  at  more 
than  one  level  of  detail. 

The  editor  maintains  a  level  of  indirection  between  the  knowledge  being  edited  and  the  representation  of  that 
piece  of  knowledge  in  the  knowledge  base.  This  is  accomplished  by  a  mechanism  like  that  of  text  editor  buffers. 
Changes  are  always  made  to  editor  definition  objects  which  are  distinct  from  the  corresponding  objects  in  the  actual 
knowledge  base.  The  stack  or  list  of  the  active  definition  objects  is  always  visible  to  the  user.  The  top  item  in  this 
list  is  the  definitioa  currently  being  viewed  and  edited.  The  user  is  fiee  to  modify  the  cuirent  definition  in  any  way 
without  directly  affecting  the  knowledge  base.  Only  when  the  modified  definition  is  to  be  placed  into  the 
knowledge  base  is  a  defining  function  a^rpropriate  to  the  type  of  knowledge  (e.g.,  clas.sification  for  concepts  and 
roles),  executed  aixl  the  knowledge  base  modified. 

Since  the  editor  stack  is  always  visible,  it  provides  one  convertient  method  for  browsing.  The  user  may  point 
at  any  definitioa  item  currently  in  the  stack.  The  object  will  then  be  displayed  in  the  same  editor  view  as  when  it  was 
last  edited. 

A  number  of  window  subsystems  or  tools  have  been  developed  and  incorporated  iiso  the  KREME  editor  to 
make  editing,  viewing  and  browsing  in  knowledge  bases  easier  and  faster.  They  are  described  below. 


3.3  The  Grapher 


KREME  is  equipped  with  a  general  graphing  facility  that  rapidly  draws  lattices  of  nodes  aid  links.  Its  main 
use  is  to  provide  a  dynamically  updated  display  of  a  concept  or  role  and  its  place  in  the  specialization  or  inheritance 
hierarchy.  When  editing  a  concept  in  the  Main  Concept  Editing  View  or  the  Big  Concept  Graph  View,  or  when 
editing  a  role,  KREME  automatically  displays  all  of  that  object’s  abstractions  and  spedalizations.  More  abstract 
objects  are  di^layed  to  the  left  of  the  current  editor  object,  and  more  specialized  objects  to  the  tight 

As  shown  in  figure  3-2,  the  cuiieul  editor  object  appears  as  a  black  node  with  white  letters.  All  other  objects 
appear  as  nodes  with  a  white  backgroundL  Objects  that  are  defined  as  primitive  are  indicated  by  boid-edged  boxes. 
Nodes  that  hawe  been  inodifled  (edited  but  not  redassified)  have  a  grey  background. 


3J.1  Panning  the  Graph 


Tbe  gibber  can  display  a  giaph  much  laiger  than  the  window  tfaiDugb  which  it  is  viewed.  To  see  a  pan  of  the 
netwoik  that  is  off  tbe  screen,  the  user  points  with  tbe  mouse  at  some  point  on  tbe  graph  window  not  containing  a 
node,  holds  the  left  button  down  and  drags  tbe  mouse.  To  speed  pan,  tbe  user  holds  down  the  middle  mouse  button 

3J.2  The  Overview  Graph 

Giddng  the  right  button  once  over  an  empty  pan  of  the  graph  window  will  make  the  Graph  Operati 
Mena  appear.  If  the  user  clicks  overview,  a  miniature  version  of  tbe  full  lattice  will  appear  in  a  black  region  in 
upper  left  comer  of  tbe  graph  window  (as  in  figure  3*3).  This  overview  shows  a  miniature  veision  of  tbe 
netwoik.  The  visible  region  of  the  graph  is  indicated  by  a  white  rectangle.  If  tbe  user  pans  with  the  mouse  over 
main  graph  window,  this  white  rectangle  will  follow  the  mouse  movements.  All  of  tbe  mouse  operations  available 
on  nodes  in  tbe  main  window  will  also  woik  on  nodes  in  this  window.  The  name  of  tbe  node  being  pointed  at  is 
indicaied  in  the  moose  documentation  window.  Tbe  overview  window  also  can  be  used  to  pan  the  main  graph 
window.  The  overview  is  turned  off  by  bringing  up  die  Graph  Operations  Menu  and  clicking  tbe  command 
overview. 


3J J  The  Graph  Operations  Menu 


The  other  options  in  tbe  Graph  Operations  raenn  shown  in  figure  3^  are; 

•  hardcopy  •  Sends  a  copy  of  the  fiiil  graph  of  the  lattice  to  the  printer. 

•  style  menu  -  Allows  the  user  to  choose  tbe  foot  style  and  size  of  characters  used  for  nodes  oo  tbe  graph. 
Smaller  foots  are  useful  to  see  more  of  large  networks  at  once. 

•  find  node  •  Prompts  for  the  name  of  an  objea  on  the  graph,  and  oenieis  that  node  on  the  graph  wiixlow. 
It  also  draws  a  drele  around  the  node  so  that  the  user  can  find  it  more  easily.  The  circle  disappears  as 
soon  as  tbe  gr^  is  panned. 

•  overview  •  Switcher  tbe  overview  graph  between  visibie  and  invisible. 

•  orientatioa  •  Switches  tbe  (Kientation  of  tbe  graph.  Normally,  the  lattice  is  drawn  ftom  left  to  right 
This  command  will  cause  the  graph  to  be  redrawn  ftom  tbe  top  of  the  screen  dowit  and  vice  versa. 

•  speed  pan  •  This  command  pops  up  the  speed  pming  bmt  witbout  having  to  hold  down  tbe  mouse 
button.  In  this  mode,  efidring  any  moose  button  win  make  it  go  away. 


•  redraw  graph  •  Redraws  the  current  graph. 
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Figure  3-4:  The  Graph  Opeiadoos  Menu 


3J.4  The  Graph  Node  Command  Menu 

Noemally.  the  KREME  Grapher  displays  only  the  abstrachons  and  spedalirations  of  the  canent  editor  object, 
because  KREME  was  designed  to  woik  with  tihe  very  large  lattices  characteiistic  of  very  large  knowledge  bases. 
The  Grapher  provides  a  number  of  options  to  enable  useis  to  tailor  the  display  to  see  more  (or  less)  than  KREME 
noimally  displays  oa  such  graphs. 

Whenever  the  mouse  is  over  a  node  on  a  graph,  the  moose  documentatiou  window  shows  the  name  of  the 
node,  followed  by: 

L:Sdlt  tills  nods.  M: Graph  Rslatlvsa  RiHanu  ot  Editing  Options 

Clicking  the  left  mouse  button  causes  KREME  to  mrire  the  object  poinied  to  the  top  editor  stack  item.  Thisis 
an  exttemety  convenient  way  browsing  through  large  concept  netwoiis  tpnckly,  and  focusing  on  different 
poftiooB  of  such  a  netwoifc.  If  however,  the  user  wisfaes  to  contiuue  editiag  the  concept  that  he  is  cunendy  viewing, 
but  see  mom  (« less)  of  the  ndtwode  around  that  concept  or  some  other  concept  on  the  same  graph,  be  can  use  the 
Graph  Rdatfvas  Mena  foond  by  clicking  the  middle  mooe  button  over  any  graph  node. 

The  Graph  Reiadvet  Menu,  exposed  by  rKHring  the  middle  button  over  a  node,  contains  the  following 
commands: 

•  Graph  Paraitts  •  canses  aD  absttactiooB  of  the  node  dkked  on  to  be  added  to  the  displayed  graph. 

•  Graph  Chidrea  -  causes  an  spedahaatioaB  of  tbs  node  clicked  on  to  be  added  to  the  displayed  graph. 

•  ffide  Children  -  canses  all  spedalizmiaiis  of  the  node  clicked  on  to  be  removed  fitom  the  graph,  unless 
they  am  alM  childrea  of  some  other  node. 


It 


•  Hide  Node  and  Cbildren  -  causes  ifae  node  clicked  on  and  its  children  to  be  removed  &om  the  graph. 


3J^  Editing  a  Network  from  a  Graph 


Clicking  the  right  button  overa  graph  node  causes  yet  another  menu  of  opdons  to  be  exposed,  the  Concept 
Graph  Edit  Options  Memi.^ 

This  mem  contains  the  following  options  for  concepts: 

•  Show  Definition  •  This  option  causes  the  textual  (LISP)  fonn  of  the  concept's  definition  to  be 
displayed  over  the  Graph  Window. 

•  Kill  Concept  -  This  causes  the  concept  pointed  to  to  be  removed  fiom  the  knowledge  base.  It  has  the 
same  effect  as  the  KiD  Concept  comma^  in  the  local  command  menu  window,  except  that  it  works 
when  the  user  is  ixx  currently  editing  the  concept  be  wishes  to  blL 

•  Rename  Concept  -  This  command  prompts  for  a  new  name  for  the  concept  pointed  to,  and  iiiunediateiy 
replaces  all  references  to  chat  name  with  the  new  name  rhrougbout  the  knowledge  base. 

•  Delete  Parent  •  This  commaod  prompts  for  the  name  of  a  parem  and  then  deletes  that  parent  from  the 
list  of  defined  patena  of  the  concept  iratially  pointed  to.  It  also  switches  KREME  to  editing  the 
concept  modified,  so  that  it  can  then  be  reclassified. 

•  Add  Parent  •  Thia  commaod  also  prompts  for  a  patent,  adds  the  concept  named  to  the  list  of  defined 
parents  of  the  concept,  and  switdies  to  editing  the  modified  coiKepL 

•  SpUce  Out  Parent  •  This  cottunand  prompts  for  a  parent,  and  removes  that  parem  fiom  the  list  of 
defined  parents  of  the  concept,  replacing  it  with  that  concept’s  parents.  Again,  tte  editor  is  switched  to 
a  view  of  the  modified  cooc^ 


3.4  Editing  in  the  State  Window 

The  state  window  of  the  Main  Concept  Editing  View  displays  basic  information  about  the  concept  currently 
being  edited.  The  top  lure  displays  the  ume  of  the  concept,  and  any  synonyms  or  alternate  names  for  that  concept. 
The  name  of  the  coocqpt  can  be  changed  by  clickmg  on  the  word  Concept:  and  enteiing  a  new  name. 

The  second  Ime  of  the  display  shows  whether  the  concept  is  defined  as  primtdve  or  not,  and  whether  the 
concept  hat  been  daaaified  or  modified  sinoe  classificatinn.  CScking  on  the  word  Primitive:  causes  the  concept  to 
be  marlBed  primitivn  if  it  was  not,  and  vice  versa. 

The  third  line  displays  both  the  dirtet  and  defined  parents  of  the  ctmeept,  after  the  word  Spedaiizes;. 
Defined  parmtu  me  concepts  ihst  the  user  specifies  as  dbsttartione  of  the  concepc  Direa  parents  are  concepts  that 
may  or  may  not  have  been  defined  as  patents  of  the  current  cue.  bat  have  been  determined  by  (be  classifier  to 


lh(  Kai*  <3nfh  Un  OyttMi  Maan 


fer  ralH,  awipi  IB  naiad. 


u 


subsume  the  class  denoted  by  tbis  concept  and  not  have  am  specializations  that  also  subsume  this  concept.  On  tbe 
Concept  Gtapb.  tbe  diiea  parents  of  a  concept  are  tbe  ones  with  direct  links  to  it 


Ibis  Specializes:  list  should  be  read  as  follows:  Concepts  that  are  uimaiked  are  both  defined  parents  and 
direct  parents.  Concepts  that  are  defined  parents  but  not  direct  parents  are  prefixed  by  a  Concepts  that  are 
direct  parents  but  not  defined  parents  are  prefixed  by  a  "-t-".  The  user  can  easily  add  a  parent  to  tbe  set  of  defined 
parents  of  the  concept. 


3.5  Editing  in  the  Table  Edit  Window 


Nocinally,  tbe  table  edit  window  in  Main  Concept  View  displays  tbe  set  of  Local  Slots  of  the  concept,  that 
is,  those  slots  which  are  defined  locally  by  this  concept  and  not  inbeiited  from  above.  The  columns  in  tbe  table  are 
labeled  "Defined  by",  "Role",  "Number  Restriction",  "Value  Restriction",  "Default",  and  "Description". 

Clicking  (with  tbe  left  moose  button)  on  the  command  AH  Slots  in  tbe  table  edit  command  window  causes 
KREME  to  display  both  local  and  inbeiited  slots.  In  ibis  display,  local  slots  are  indicated  by  the  word  "LOCAL*  in 
tbe  "Defined  by"  coimnn  of  the  table.  Slots  infaeriled  from  a  parent  show  the  name  of  that  parent.  Slots  foimed  by 
oombining  the  value  lesoictions  and/or  number  restiictioos  of  several  parents  are  indicated  by  tbe  word 
•CLASSIFIER*.  When  tbe  table  window  is  displaying  all  of  tbe  concept’s  slots,  tbe  user  can  retnm  to  viewing  just 
tbe  local  ones  by  clicking  tbe  command  Local  Slots. 

Whenever  the  Table  Edit  Window  shows  slots  of  the  cuxiem  concept,  tbe  user  can  edit  those  slots  or  add  new 
ones.  To  change  tbe  slot  name,  value  resinction,  nomber  restriction,  default,  or  description  of  a  slot,  tbe  user  simply 
clicks  the  left  mouse  button  over  tbe  thing  to  be  ebanged,  and  will  be  prompted  for  a  lepiacement.  For  all  but 
number  lestrictioos.  the  right  button  win  pop  up  a  mem  that  includes  tbe  commands:  Change  tbe  part  of  tbe  slot 
pointed  to.  Show  Definitioa  of  the  concept  or  role  poinied  to.  Edit  Defimtion  of  that  concept  or  role,  or  pop  up  a 
Graph  of  its  abstractions  and  specializatiotis.  When  pointing  to  tbe  slot  name,  in  the  column  labeled  "Role",  tbe 
user  can  also  Rename  Role,  that  is,  change  the  name  trf  tbe  role,  and  aO  references  to  it  in  tbe  knowledge  base. 

When  tbe  mouse  is  over  a  line  in  the  slot  table,  and  tbe  entire  liis  is  eodrcled  by  a  box,  the  right  mouse  button 
can  be  used  to  get  a  mem  of  Ddetu  Slot,  Copy  Slot  to  another  concept,  and  Move  Slot  to  another  concept.  For  tbe 
last  two,  KREME  promps  far  the  name  far  tbe  concept  to  move  or  copy  the  slot  to. 
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3J.1  Adding  New  Slots 


Wbeoever  the  slots  table  window  is  visible,  as  in  tbe  Main  Concept  Editing  View,  tbe  user  can  add  new  local 
slot  definiticas.  A  new  slot  is  added  to  tbe  defined  slots  of  the  concept  with  tbe  Add  Sot  command.  When  this 
command  is  issued,  tbe  system  prompts  for  a  role  name,  a  value  Rsaictioa,  a  number  resihction  and  a  default  fonn. 
Any  of  these  items  can  be  eoteied  by  typing  or  by  pointing  to  tbe  desired  name  or  fonn  if  it  is  visible. 

If  a  role  or  concept  named  in  a  role  lestnctioa  or  default  does  not  exist  tbe  system  will  ofo  to  make  one  with 
tbe  name  given,  and  proceed  to  pop  up  tbe  defining  foim  for  that  object  Wben  the  user  is  finished  filling  out  the 
fonn,  he  clicks  Define,  and  KREME  will  continue  to  ask  for  tbe  test  of  tbe  new  slot's  features. 

When  tbe  user  has  finished  adding  and  modifying  tbe  slots  of  a  concept  be  should  always  make  tbe  changes 
pennanent  with  (be  Qassiiy  Cooccpt  command. 

3,5.2  iVfodiryfiig  the  Table  Edit  Window 

The  igjpearance  of  Table  Edit  Windows  can  be  modified  in  several  ways.  The  tables  are  scroUabie  in  both  the 
up-down  and  left-iigbt  directiOfisJf  ifae  user  does  not  wish  to  see  some  columns  of  the  table,  they  can  be  selectively 
removed. 


3,5  J  Changing  the  Contents  of  the  Table  Window 

Since  there  is  not  enough  room  in  the  Main  Concept  Editing  View  to  display  all  of  a  concepts  defining 
ftamres  at  one  time,  tbe  coatencs  of  tbe  Table  Edit  Window  can  be  changed  to  di^lay  those  other  foatnres.  To  do 
this,  the  user  must  use  tbe  mouse  to  find  tbe  table  window  contents  menu.  TUs  menu  is  available  wherever  there 
is  ootfaing  else  under  the  mouse  while  still  inside  tbe  table  window,  tbe  user  will  know  be  has  found  it  because  tbe 
moose  docnmentadoa  window  will  show  the  words: 

R:  Chnagn  thn  eontnnhs  o£  this  tnblo. 


Wben  tbe  user  dkks  (be  dgtx  button,  he  win  see  the  following  menu  options: 

•Slots  -  Displays  the  table  of  this  concept’s  slots,  as  desctfoed  above. 

•  hmrse  Restrictions  -  Displays  a  table,  csseotiatty  like  the  slots  taUe,  bat  of  aO  of  tbe  slots  displayed 
are  sioa  of  oibsr  concepts  tbit  use  the  current  coiscept  as  their  value  ratriaion.  This  table  is  useful 
when  tneby  wftteuces  to  a  concept  in  other  concepts.  Wben  this  table  is  displayed,  the  tabic  edit 
cumasand  window  win  be  empty.  Some  of  the  editing  options  desoibed  for  the  slots  table  wiU  not 
woikbeie. 

•Stot  Egnirelincee  •  Tliie  able  displ^  (be  slot  eqnivalenoee  of  ibe  canent  editor  concept  This  table 
has  0^  three  cobmue,  "Defined  by”,  "FWh  1"  sod  "Fntfa  2”.  Tbe  two  paths  are  designated  as 
denoting  Ibe  same  object  Since  slot  tqnivaisiicu  can  be  iaheoted.  ifaeir  source  is  also  indicared  in  tbe 
taUo,  in  tbe  cnlnmn  "Defined  by".  When  ibis  ttiUe  it  visiMe,  tbe  table  edit  command  window  win 
show  the  cnmminili  Local  IqnivalenciS,  AI  EtyrivalmcM,  md  Add  Eqprivalencfc  Tbe  fiat  two  just 
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change  wbkb  equivalences  are  displayed.  The  last  {Rtaapcs  for  two  slot  paths  that  should  be  made 
equtvalenL 

•  Disjoint  Concepts  •  This  table  is  jnst  a  one  column  list  of  all  of  the  coocepa  that  ate  defined  to  be 
disjoint  from  the  one  cnnently  being  edited.  When  this  table  is  visible,  the  Table  Edit  Command 
wiaiow  will  displqt  the  conunands  Add  Disjoint  Clasa,  Local  Disjoint  Classes,  and  All  Disjoint 
Classes. 


3.6  Files  and  Multiple  Language  Support 

All  definitions  manipulated  by  the  editor  are  read  and  stored  in  lisp-readable  text  fii***  of  defining  foims. 
Since  these  files  contain  foimaited  lisp  fotms,  they  are  user-readable,  and  can  be  edited  offline  using  an  oidinaiy 
text  editor.  In  bet,  KREME  can  as  easily  read  files  that  were  developed  ind^tendently  using  a  text  editor  or  some 
other  frame  editor. 

POes  are  read  in  using  the  LOAD  command.  A  file  can  be  loaded  into  a  blank  KREME  knowledge  base  or 
can  be  loaded  on  top  of  an  already  existing  knowledge  base.  This  mechanism,  which  relies  heavily  on  the  the  frame 
classifier  to  maintain  consistency,  enables  KREME  to  organize  infonnation  from  multiple  knowledge  bases  to  create 
a  single  unified  whole. 

KREMEcunendy  reads  and  writes  definitioas  in  either  its  own  frame  language  syntax  or  NIKL  syntax.  This 
flexibility  has  nude  it  passible  fyt  KREME  to  be  used  iegtilaily  to  examine  and  update  a  knowledge  base  of 
approximately  1000  roles  and  concepts  far  the  IRUS/TAMUS  tumral  language  inteiface  that  was  built  using  NIKL. 
KREME  can  also  read  files  of  MSG  (the  frame  language  of  the  STEAMER  [22]  system)  defimng  foims,  providing 
access  to  the  extensive  STEAMER  knowledge  base  of  concepts  and  procedures.  We  ate  cuiiently  building  an 
interface  to  files  of  KEE  frame  definitians. 

TUs  multiple  language  handling  bdlity  is  a  oudal  feature  of  KREME.  A  library  of  input  translation 
piogiams  will  enable  a  knowledge  base  boiUer  using  KREME  to  draw  upon  previously  m-wing  knowledge  bases  to 
create  new  knowledge  bases. 
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4.  The  KREME  Frame  Editor 


Tfais  section  wiU  desaibe  tlie  fCREME  knowledge  editor  for  a  frame  lepresentadon  language. 


4.1  The  KREME  Frame  Language 

A  number  of  frame  languages  have  been  developed  in  recent  yeais  to  suppon  AI  systems 
[12, 2, 18, 9, 3, 6, 8].  These  languages  bave  all  been  weQ  leseaicbed  and  extensively  tested.  For  KRME,  our  most 
impoitant  ciiieha  for  a  suitable  firame  repieseaiatioo  language  were  that  it: 

1.  Allowed  multiple  intaeiitance 

2.  Was  a  logicaUy  woiked  out  mature  language. 

3.  Had  some  mechanism  for  imemal  consistency  cheddng. 

4.  Was  built  on  a  modular  object  otienied  base  so  that  the  language  could  be  decomposed  in  such  a  way  as  to 
make  it  ea^y  extensible. 

NKL  (the  definitional  or  firame  language  component  of  KL>TWO)  [9,  IS,  21]  seemed  an  ideal  candidate.  It  is 
a  fully  worked  out  fiame  representation  language  that  allows  multiple  inheritance,  is  reasonably  expressive  and. 
perhaps  most  importandy,  was  designed  to  work  eOecdvely  with  an  automatic  classification  algorithm  that  could  be 
easily  adapted  to  provide  a  poweiful  mechanism  for  consisteocy  checking  and  enforcement  during  knowledge  base 
developmenL  However,  no  objea-oiiented  impiemeittaiion  of  NKL  existed,  and  the  NIKL  classifier  was  not 
designed  to  allow  modification  and  reckasification  of  previously  defined  concepta  A  second  frame  language, 
known  as  MSG,  bad  been  built  as  part  of  BBN’s  STEAMER  project  and  is  object  odented  in  both  of  the  above 

To  develop  KREME,  we  elected  to  reimplement  NIKL  as  an  object  oriented  language  using  MSG  as  a  guide. 
The  NKL  data  stnctmes  were  decomposed  into  a  modular  tderucfay  of  flavor  definitioiis,  and  the  KREME  frame 
language  was  then  buiR  out  of  these  flavors.  This  enabled  us  to  incotporaie  the  sophisticated  instantiation 
mechanism  of  MSG  with  minimal  efifott  In  the  process,  we  were  also  able  to  implemem  a  modular  version  of  the 
NKL  classifier  afforithm.  This  provided  the  kiiid  of  ledassification  capaMlity  required  for  a  knowledge  editing 
envifooraem  and  anticipnKd  the  extensioa  of  the  dassifier  to  deal  with  the  richer  semantics  of  languages  like 
InaeOicoip’s  KEE  [fi]. 
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4.1.1  Frame  Language  Syntax 

Tbe  lemainder  of  ttais  sectiaa  win  briefly  describe  tfae  bask  definitional  syntax  of  the  KREME  Firame 
i«njiay»  As  ttiis  syotax  closely  lesembies  tbe  fonnal  syntax  of  NIKL  interested  leadeis  are  refened  to  [9]  for  more 
detaiL 


Following  NIKL.  a  KREME  flame  is  called  a  concept,  Collectioos  of  coocqxs  are  organized  into  a  rooted 
inJuritance  or  subsumption  lattice  someoines  referred  to  as  a  taxonomj  of  concepts.  A  single  distinguished  concept, 
osnally  called  THING,  serves  as  tbe  root  or  most  general  concept  of  tbe  lattice.  A  concept  has  a  name,  a  textual 
description,  a  primitiveness  flag,  a  list  of  concepts  that  it  specializes  or  is  subsumed  by,  a  list  of  slots,  a  list  of  slot 
equivalences,  and  a  list  of  concepts  that  it  is  disjoint  from. 

The  lists  of  slots,  slot  equivalences  and  disjoint  concqjts  are  collectively  referred  to  as  the  features  of  a 
coneqx.  If  each  concept  can  be  thought  of  as  defining  a  unique  category,  then  features  of  tbe  concept  define  tbe 
necessrey  conditions  for  indusioa  in  that  category.  If  a  concept  is  not  marked  as  primitive,  tbe  features  also 
constitute  tbe  complete  set  of  sufficient  cooditioos  for  indusioa  in  that  category.^  A  concept  inherits  all  features 
flom  those  concepts  above  it  in  the  lattice  (those  coacepis  that  subsume  it.  and,  thus,  are  mote  general)  and  may 
define  additional  features  that  serve  to  distinguish  it  flom  its  parein  or  parents. 

Slots  (sometimes  called  rale  lestrictioos)  consist  of  a  role  or  slot  name,  a  value  restriction,  a  number 
restriction  and  an  (optional)  definlt  fotm.  tbe  value  restriction  jqredfiea  tbe  class  of  concepts  allowed  as  values  for 
thatsloc  As  in  NIKL,  valne  lestrictioos  usually  specify  a  particular  concepL 

Slot  Equivalences  describe  slots  (and  slots  of  slots)  that  by  definition  most  always  refer  to  tfae  same  entities. 

Tbe  role  name  ^tecified  far  each  KREME  slot  lefias  to  an  object  called  a  rale.  Roles  in  KREME,  as  in  NIKL 
and  several  other  flame  languages  like  KRYPTON  [3],  and  KnowledgeCraft  [8],  are  actually  distinct,  first  class 
objects  that  form  tbeir  own  distina  taxonomy,  mated  at  tbe  most  general  possible  rale,  usually  called  RELATION. 
Roles  describe  two  place  idatioos  between  concepts.  A  role  restriction  at  a  concept  is  thus  a  specification  of  tbe 
ways  a  gtven  role  can  be  used  to  lelale  tfaat  concept  to  other  concepts. 
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4.2  Using  the  Frame  Editor 


The  KREME  ftune  editor  bee  five  views,  the  Main  Concept  Editing  View,  the  Alternate  Concept  Editing 
View,  ttie  Big  Graph  View,  and  the  Macro  Slmctnre  Editor  View.  Roles,  which  ate  also  part  of  the  KREME 
Ecame  language,  ate  edited  with  the  Role  Editing  View.  In  this  section,  we  will  cover  the  details  of  the  editing 
opeiatioos  available  in  the  fiist  three  of  these  views. 

4,2.1  Editing  in  the  Main  Concept  Editing  View 

Nonnally,  when  one  creates  a  new  concept  or  edits  a  coocqK  for  the  first  tune,  KREME  makes  that  concept 
the  top  concept  on  the  Editor  Stack,  and  switches  to  display  the  Main  Concept  Editing  View.  There,  KREME 
displays  the  concept  as  it  exists  at  that  tune. 

Hgure  3-2  shows  how  the  graph  window  immediately  displays  aU  of  the  abstcactioas  and  specializadoos  of 
the  concept  being  edited,  the  sutc  window  shows  its  name,  whether  it  is  primitive  or  not.  its  edit  state  (classified  or 
not.  modified  or  ootX  ia  peients,  and  a  textnal  desoiptioa.  The  table  window  simultaneously  displays  all  of  the 
concept’s  locally  defined  slots. 

4J.2  Frame  Editing  Operations 

Space  does  not  pennit  a  full  desciiptioo  of  the  fuacaonality  of  the  KREME  fiame  editor  so  we  will  very 
briefly  touch  upon  a  few  of  its  more  impoitaot  opeiatioos. 

Making  new  ooocepts.  Hie  Ntw  Concept  commaiid  in  the  global  conunand  menu  iniiiates  the  definition  of  a 
new  concept  that  is  (1)  fitSy  specified  by  the  user,  (2)  similar  to  some  already  defined  concqx,  or  (3)  a 
specialiratioo  of  one  or  several  other  defined  concepts.  When  the  initial  fonn  for  the  oew  concept  has  been 
iyecified  the  system  creates  a  new  concept  definition  for  it  and  shows  this  new  definition  in  the  main  concept  view. 

Ihe  user  is  then  fitee  to  add  details  (slots,  eqoivsienoes,  additional  parens,  etc.)  to  the  oew'^  concept  definitioo,  s. 
classify  it.  or  edit  other  concepts. 

Adding  sad  reodRyinf  slots.  Whenever  the  window  di^ilxyiiig  slos  is  yaMe,  skxs  can  be  added  or 
modified.  A  new  slot  is  added  to  the  defined  slos  of  the  concept  with  the  Add  Slot  command.  Any  poitioa  of  a 
slot’s  definition  can  be  entered  by  typing  or  by  pouting  to  a  visiUe  reference  to  the  desired  item.  When  a  role  or 
cooo^  name  that  is  not  defined  is  specified,  the  system  ofifeis  to  make  one  with  the  oame  given. 

Usea  mtf  inodUy  any  locaBy  defined  dot  or  inbenied  slot  Skxs  shown  in  table  windows  are  modified  by 
pointing  at  the  appropriate  anbftim  and  then  either  typing  in  or  pointing  to  a  replacenrent  form.  Modifying  an 
inherited  shx  canaes  the  new  definition  to  be  locally  de&xd. 
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Adding  and  Deleting  parents.  The  system  displays  the  classifier  detennined  parents  of  a  concept  in  two 
places.  The  oonoept  graph  displays  them  as  part  of  the  abatnedon  hienicfay  of  the  concept,  and  the  state  pane 
imtiraf*  boifa  ttw  aod  direct  or  comptaed  parents  of  the  concept  after  the  word  "Specializes:'’.  Since  the 

eianaHtiT  may  have  ftiond  that  the  concept  beu^  edited  ipedaiitee  some  concepts  more  qiedfic  than  those  given  as 
its  defined  parents,  parents  that  are  not  direct  pareots  are  preceded  by  a  while  classifier  detennined 

parents  that  were  not  defined  parents  are  preceded  by  a 

Adding  new  defined  parents  to  a  concept’s  definition  is  done  by  diddng  on  the  word  "Specializes:"  in  the 
state  window  and  typing  a  concept  name  or  pointing  to  any  visible  concept.  Patents  can  be  deleted  by  clicking  on 
their  names  in  the  list  of  parents  displayed  in  the  state  window. 

OMwgtny  nantes  and  idlHng  concepts  and  roles.  KREME  allows  the  user  to  change  the  names  of  concepts 
and  .roles  or  to  delete  them  compimely.  Name  changing  is  accomplished  simply  by  poinbog  at  the  concept  or  role’s 
name  in  the  state  window  aod  enteting  a  new  name.  The  Kill  command  splices  a  concept  out  of  the  taxonomy  by 
connectitig  an  of  its  ctuldren  to  all  of  its  parents. 
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5.  Large-Scale  Revisions  of  Knowledge  Bases 


As  knowledge  bases  grow  larger,  and  tbe  ses  of  tasks  that  imelligeot  systems  are  called  upon  to  perform 
expands,  system  developea  win  need  automatic  methods  for  revising  and  lefotmiilating  accumulated  knowledge 
bases.  Toward  this  end,  we  feel  that  it  is  imponaiit  to  find  ways  of  expressing  reformulations  of  sets  of  frames  and 
other  lepiesentaiiotn  and  to  begin  developing  faeiiing*  suppoiting  the  generahoo  of  new  tepresentanons  from  old 
ones. 


We  ate  taking  two  difieient  approaches  to  these  problems.  First,  we  have  developed  a  macro  facility  for 
refbrmulatioiis  that  can  be  expressed  as  sequences  of  standard.  low>Ievel  editing  operahoos.  This  facility  allows 
uaeis  to  use  an  example  to  define  editing  macros  that  can  be  applied  to  sets  of  frame  definitions.  Second,  we  are 
building  a  library  oi  fbnctioas  {Koviding  standard  editing  operations  that  cannot  be  defined  simply  as  sequences  of 
low  level  editing  opecatiotis.  Our  tnain  purpose  in  this  project  is  to  collect  and  categorize  a  number  of  different 
kinds  of  knowledge  base  lefotmuladoas.  Our  hope  is  that  a  large  fractioa  of  these  operations  can  be  conveniently 
desoibed  using  the  macro  facility,  as  it  is  more  accessible  to  an  experimental  user  community  than  any  set  of 
’‘prepackaged**  utilities,  and  can  be  more  responsive  to  the,  as  yet,  largely  unknown  special  needs  of  that  community 


5.1  The  Macro  and  Structure  Editor 


One  of  tbe  viesvs  available  when  editing  concepts  in  KR£ME  is  tbe  macro  and  structure  editor.  This  view 
(See  figure  5-1.)  provides  display  and  editing  facilities  for  concept  <tgfinitinn«,  based  loosely  on  tbe  kind  of  structure 
editor  provided  in  many  LISP  environments.  The  view  provides  two  windows  for  the  display  of  stylized  defining 
forms  fm  coocqna.  The  current  edU  window  displays  the  definition  of  tbe  currently  edited  concept  (tbe  top  item  on 
the  editor  stack).  The  display  window  is  available  for  the  display  of  any  number  of  other  concepts.  Any  concept 
which  is  visible  in  either  window  can  be  edited,  and  features  can  be  copied  from  otk  concept  to  another  by  pointing 
Both  windows  am  scrollable  to  view  additional  definitioos  as  required. 

Them  is  a  menu  of  rommandt  for  displaying  and  editing  definitiois  that  includes  tbe  commands  Add 
Stracture^  Oieiige  Sfeuchwe,  IMaSe  Sftmcfnre,  Dfeplay  Cooocpt  and  Clear  Display.  Arguments  (if  any)  to 
these  commamls  ouy  be  described  by  painting  or  typing.  Thus,  to  delete  a  slot,  one  simply  clicks  on  Delete 
Sinsctnre  and  the  display  of  the  slot  to  be  deleted.  Adding  a  stnctum  is  done  by  clicking  on  Add  Structure,  tbe 
keyword  of  die  fnmm  daes  of  the  oonoept  one  wishes  to  add  to  (e.g.,  SloC:).  The  new  slot  itself  may  be  copied  from 
a  displayed  concept  by  pointing,  or  a  new  one  may  be  entered  from  the  keyboard.  CStangirv  (thm  is,  replacing)  a 
sBoctum  can  be  dotw  by  painting  in  soocesnon  at  the  rhange  Structure  command,  the  item  to  be  replaced,  md  tbe 
thing  to  replace  k  with.  In  moac  cases,  fhenge  Structure  can  also  be  invoked  simpty  by  poiming  at  the  structure  to 
bs  replaced,  wkhout  the  inemi  command. 
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FlgimS'l:  Tbe  Macro  Smictmc  Editor  View 


Tbe  last  two  coaunaods  in  tfae  stnicoiie  view’s  main  mean  provide  tbe  meaos  to  ebaoge  wbat  is  displayed  in 
tbe  display  window.  Pointing  at  Display  Stractore  and  then  any  visible  concept  name  places  tbe  definition  of 
that  concept  in  the  display  window,  Qcar  Display  removes  aU  items  from  tbe  display  window.  Individual  concepts 
rati  be  Grom  tbe  display  window  by  pointing  at  tbem  and  clicking.  Tbe  Edit  Concept  command  is  used  to 

cfaangp  wbat  is  displayed  in  tbe  current  edit  window.  Editing  a  new  concept  moves  tbe  old  edit  concept  to  tbe 
bottom  of  tbe  display  window. 

\ 

5.2  Developing  Macro  Editing  Procedures 

These  opentioas,  together  with  tbe  globally  available  commands  for  defining  new  concepts  and  making 
specialiaaiioasof  old  concepts  essentially  by  copying  tbeirdefinitioos,  provide  an  extremely  flexible  environmern  in 
wliidi  to  dote  and  specify  modificaiinoB  of  concepts  with  respect  to  other  defined  concepts.  Viitnally  all 
knoiriedgB  editing  opendons  can  be  done  by  a  sequence  of  poinfing  steps  using  tbe  current  edit  window  and  tbe 
dispfaqr  window.  This  style  of  etStinf  is  also  used  in  tbe  rale  editor.  Tbe  combinadon  of  editing  firaraies  and 
aioaee>lMsed  editor  ioteraction  style  provides  an  extremely  versadie  eavinanieat  for  tbe  desexipdoa  by  example,  of 
a  laqiB  daM  of  etfiting  maciDt. 


bi  Older  to  have  macros,  defined  essentially  by  example,  wodt  on  concepts  other  than  chose  for  which  they 
were  defined,  the  operations  recorded  cannot  refer  directly  to  the  concepts  or  objects  which  were  being  edited  when 
the  nucro  was  defined.  Hiis  is  tianriw  by  a  land  of  implicit  variablizaiion,  where  the  objects  named  or  pointed  to 
are  replaced  by  references  to  their  reladonship  to  the  initiaily  edited  objecL  In  most  cases,  these  indirect  references 
can  be  thought  of  as  references  to  the  location  of  the  abject  in  the  structure  editor’s  display  windows.  In  feet,  each 
new  object  that  is  displayed  or  edited  in  the  course  of  defining  a  macro  is  placed  on  a  stack  called  the  macro  items 
list^  together  with  a  pointer  to  the  command  that  caused  the  item  to  be  displayed.  The  utility  of  this  form  of 
reference  will  become  dearer  with  an  example. 

5J.1  Macro  Example:  Adding  Pipes  Between  Components 

When  the  STEAMER  [22]  system  was  developed,  a  structural  model  of  a  steam  plant  was  created  to  represent 
each  component  in  the  steam  plant  as  a  frame,  with  links  to  all  functionally  related  components  (e.g.,  inputs  and 
outputs)  represented  as  slots  pointing  at  those  other  objects.  So,  for  example,  a  tank  holding  water  to  be  fed  into  a 
boiler  tank  through  some  pipe  that  was  gated  by  a  valve  was  represented  as  a  frame  with  an  OUTPUT  slot  whose 
value  was  a  VALVE.  The  OUTPUT  of  that  VALVE  was  a  BOILER-TANK.  The  pipes  through  which  the  water 
was  conveyed  were  not  represented  since  they  had  no  functional  value  in  the  simulation  model.  If  it  had  become 
importam  to  model  the  pipes,  e.g.  because  they  introduced  Metion  or  were  susceptible  to  leaks  or  explosions,  then 
the  representational  model  that  STEAMER  relied  on  would  have  required  massive  revision.  Each  component  objea 
in  the  system  would  have  needed  editing  to  replace  the  objects  in  its  INPUT  and  OUTPUT  slots  with  new  frames 
representing  pipes  that  were  in  turn  connected  by  their  OUTPUT  slots  to  the  next  component  in  the  system. 

One  of  our  goals  in  develt^ring  the  KREME  macro  editor  was  to  be  able  to  make  suen  changes  easily.  While 
they  are  simple  to  describe,  they  noimally  require  many  tedious  editing  operations  to  a  large  number  of  concepts. 
Figure  3'2  shows  a  macro  that  can  be  applied  to  ail  objects  in  a  system  with  INPUT  and  OUTPUT  slots,  in  order  to 
generate  and  insert  PIPEs  into  ttxMe  dots.  The  macro  also  rets  the  OUTPUTS  of  those  PIPEs  to  be  the  concept  that 
was  the  old  value  of  the  OUTPUT  slot  in  the  concept  edited,  aixl  similariy  redoes  all  INPUTS. 

Hgure  5-2  shows  how  the  macro  is  defined,  by  editing  a  representation  of  a  tank  (TANKl)  connected  (by  role 
OUTPUT)  to  a  valve  (VALVE2).  The  sequence  of  steps  requited,  defined  only  using  the  mouse,  is  shown  in  figure 
3-2,  as  they  would  appear  in  the  Macro  Definition  wmdow  of  the  editor. 

In  Phase  One,  work  on  macro  editing  was  only  just  begun.  However,  tins  techniqae  already  shows  promise  as 
ametbod  for  accomplishing  testroctiBings  of  knowledge.  We  see  our  investigation  of  macro  editing  as  only  the  first 
srep  in  developing  a  knowledge  reformulation  facility  that  will  make  use  of  the  higher  level  structure  of  the 
reprejanicd  knowledge. 
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1.  Make  a  new  concept  which  specializes  PIPE.  (Creates  PIPEO  as  item  IX 

2.  Change  the  INPUT  value  restnetion  of  item  1  (^/i*£S0)to  item  OITAA/XU). 

3.  Change  the  OUTPUT  value  lestnction  of  item  1  (PfPEO)  to  the  OUTPUT  value  resmetion  of  item  0 
(OUTPUT  cf  TANKl  mVALVEl). 

4.  Qasaify  the  cunent  edit  concept  (Opines  PIPED). 

5.  rwup  the  OUTPUT  value  lesniction  of  item  0  (>  VALVEl)  to  item  1  (PIPED). 

6.  Classify  item  0  (JANKl). 

7.  Edit  the  OUTPUT  value  lestriction  of  item  1  (Creates  item  2  »  VALVEl). 

8.  Change  the  INPUT  value  icsttiction  of  item  2  (INPUT  (^VALVEl  »  TANKl)  to  item  1  (PIPED). 

9.  Classify  all  items. 


Figure  5*2:  Steps  in  PIPE  Macro 
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6.  Knowledge  Integration  and  Consistency  Maintenance 


One  of  the  most  time  coasnmiag  tasks  in  building  laige  knowledge  bases  is  maintaining  internal  consistency. 
Modificanon,  additioa  or  deletion  of  knowledge  in  one  pan  of  a  knowledge  base  can  have  wide  tanging 
consequences  to  both  the  meaning  and  stnctuie  of  the  knowledge  stored  in  other  paits  of  the  knowledge  base.  A 
central  component  of  the  KREME  system  des^  was  that  it  incoipoiaie  tools  for  consistency  maint»nanri»  both 
within  and  across  representation  languages.  These  toots  are  collectively  referred  to  as  the  knowledge  integrator. 
When  new  knowledge  is  entered  or  existing  knowledge  modified  it  is  the  task  of  the  knowledge  integrator  to 
propagate,  throughout  the  knowledge  base,  the  changes  that  this  new  or  modified  knowledge  entails,  and  to  repoit 
any  inconsistencies  that  have  been  caused  by  the  change. 

In  essence,  the  knowledge  integrator  takes  each  new  ot  changed  chunk  of  knowledge  (e.g.,  a  frame,  role,  rule 
or  procedure)  and  deteimines,  first,  how  the  new  definition  fits  into  the  knowledge  base  and,  second,  which  other 
definitions  depend  on  the  cutient  one  for  their  meaning  within  the  knowledge  base.  These  dependencies  are  placed 
on  an  agenda  which,  in  turn,  causes  them  to  go  through  essentially  the  same  process. 

The  knowledge  integcuioo  subsystem  for  frames  is  basically  an  extension  of  the  classification  algorithm 
developed  for  the  NIKL  representatioa  language.  The  NDQ.  classifier  comedy  inserts  new  fiames  into  their  proper 
spot  in  a  taxonomy,  by  finding  the  most  specific  set  of  concepts  whose  definitioas  subsumed  the  definition  of  the 
new  concept.  The  KREME  classifier  was  designed  to  additionally  allow  existing  concepts  and  roles  to  be  modified 
and  and  then  reclassified,  $o  that  the  effects  of  redefinitioos  are  automatically  propagated  throughout  the  entire 
frame  network.  This  svas  aoconqilished  by  redesigning  the  original  NIKL  classifier  to  take  advantage  of  the 
meta>level  descriptions  of  KREME  Frames  and  implementing  the  new  classifier  using  the  dependency  directed 
agenda  mechanism  of  the  overall  knowledge  integrator. 


6.1  The  Frame  Classifier 


The  lenuunder  of  this  section  svill  give  a  taief  descriptkm  of  the  frame  classification  part  of  the  knowledge 
integrator,  svtdch  is  the  most  completely  developed  portion  of  the  system.  For  a  formal  description  of  the  NIKL 
daasifter  algoiitfara  see  [15,  Ifi].  For  a  m«e  complete  description  of  a  somewhat  simpler  classifier  for  an  editing 
environment,  see  [1]. 

The  frame  dasaifiCT  works  in  essentially  two  stages,  starting  from  a  concept  or  role  d^nition,  as  supplied  by 
the  editor  or  read  from  a  file.  The  first  stage,  called  completion,  refers  to  the  basic  inhentaoce  mechanism  used  by 
KREME  Rames  to  install  aO  inlieriied  feaoires  of  a  oonoept  or  role  in  its  internal  descriptioiL  The  completion 
algoritfam,  when  given  a  set  of  defined  parents  sod  a  set  of  defined  features  for  an  objea  deteimines  the  frill, 
loficaOy  entailed  set  of  features  of  that  object  The  second  stage  is  the  actual  classification  or  reclassification  of  a 


23 


role  or  conoepc  That  is,  the  detenninatioa  of  the  complete,  most  specific  set  of  parents  of  the  objea  in  its  respective 
sohsumpdon  hietaxcby. 

6.1.1  Completion 

The  completion  algorithm  is  brokea  up  into  modular  chm**  that  cotrespood  to  the  decomposition  of  the 
frame  language.  There  is  a  HiaHnct  component  that  deals  with  slot  inheritance,  another  component  that  deals  with 
disjoint  inheritance,  a  tfaiid  that  deals  with  slot  equivalence  inheritance  and  so  on.  This  organization  makes  it 
quite  stxaightforwaid  to  extend  the  language  with  new  fieatures  that  handle  inheritance  in  different  ways. 

Hgnie  6>1  shows  some  of  the  complexities  of  slot  inheritance.  La  6-lA,  the  most  specific  value  restricaon  for 
the  slot  LIMBS  at  4-LlMBED-ANIMAL  is  inheriteri  frmn  one  parett  (ANIMAL)  while  the  most  qjedfic  number 
restriction,  EXACTLY  4,  is  inherited  from  4.LIMBED-THING.  The  completion  algorithm  detennines  that  the 
restiictioo  for  the  role  LIMBS  at  the  concept  4.LIMBED-ANIMAL  must  be  EXACTLY  4  LIMBS. 

Hgure  6-lB  shows  one  case  for  which  the  effective  value  restriction  must  logically  be  the  conjunction  of 
several  concepts.  Since  ANIMAL-WITH-LEGS  is  both  an  ANIMAL,  and  a  THING* WTTH-LEGS,  all  of  its 
LIMBS  must  be  both  ORGANIC-LlMBs  and  LEGs.  If  the  concept  ORGANIC-LEG,  specializing  both  ORGANIC- 
UMB  and  LEG,  exists  when  ANIMAL-WITH-LEGS  is  being  dassified,  the  integrator  wiU  find  it  and  make  it  the 
value  restricrion  of  the  slot  LEGS  at  ANIMAL- WTIH-LEGS.  If  it  does  not  exist,  the  integrator  stops  and  asks  if  the 
user  would  like  to  define  it  (that  is,  define  a  concqit  that  is  both  an  ORGANIC-LIMB  and  a  LEG). 


6.1.2  Classification 


The  second  suge  of  the  frame  classification  algorithm  finds  all  of  the  mots  specific  subsumers  of  the  concept 
being  defined  of  redefined.  This  is  the  actual  classification  stage,  and  is  essentially  a  spedal-fnipose  tree  walking 
algorithm. 

The  basic  dassifier  aigtnitfam  takes  a  completed  definitioo  (that  is,  a  definition  pins  all  its  effective,  inherited 
feamies)  and  detennines  that  defimdoo’s  sing^  appropriate  spot  in  the  lanice  of  previously  dassified  definiiioos. 
The  result  of  a  dassificatioo  is  a  unique  set  of  the  most  specific  objects  that  subsume  the  definitioo  and  a  unique  set 
of  the  moat  genend  objects  that  are  tnbsumed  by  the  definitioo,  When  the  daitififd  definiiion  is  installed  in  the 
laitioe  all  the  concepts  that  subsume  in  features  will  be  above  it  in  the  laitioe  and  all  the  concepts  that  are  subsumed 
by  its  feamres  will  be  below  it. 

The  dsisifirr  is  built  around  a  moddaity  consuucted  subsomptioo  rest  thst  compares  foe  completed  sets  of 
feamres  of  two  objects.  The  objea  being  dassified  is  repeatedly  compared  to  other,  potenridly  related,  objects  in 
foe  lattica  u  sec  whether  its  coaqdered  definiiioa  subsumes  or  is  sabsomed  by  those  other  objects.  For  one 
definition  u  subsume  the  other,  hs  flili  sa  of  features  must  be  a  snbsa  of  foe  feamres  of  foe  other.  As  with 
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Conjoined  Value  Restrictions. 
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completioo.  gitxwmpttoo  testing  is  panitiooed  by  fieaime  type  (Le  slot,  disjoim-class  etc).  One  object  tbe 

otber  when  all  of  its  individiial  fieatuie-type  subsumption  cfaeda  leatm  EQUIVALENT  or  SUBSUMES,  and  there  is 
at  least  one  vote  for  SUBSUMES.  Tbe  advantage  of  this  kind  of  modular  organizatioa  is  extensibility.  If  a  new 
fisamre  type  is  added  to  tbe  language  one  need  only  define  a  subsumption  predicate  for  that  foainre,  and  objects 
baying  that  foatuxe  will  be  appropdaiely  classified. 


6.2  An  Example  of  Reclassification 


The  power  of  frame  reclassificatioa  in  an  editing  environment  can  be  iOnstiated  with  the  following  leiatively 
simple  example.  Suppose  a  knowledge  base  developer  bad  defined  both  GASOLINE-POWERED-CAR  and 
IN  1  EkNAL'^XJMBUSTION'POWERED'CAR  as  spedaUzatioos  of  CAR.  but  had  madveneotly  defined 
INTERNAL-COMBUSnON-ENClNE  as  a  kind  of  GASOLINE-ENGINE.  In  this  situaiioo,  the  classifier  would 
deduce  that  INTERNAL-COMBUSTION-POWERED-CAR  must  be  a  speciaHraiion  of  GASOLINE-POWERED- 
CAR,  as  shown  in  figure  6-2  A.  since  the  fonner  restiicied  tbe  role  ENGINE  to  a  subclass  of  tbe  latter’s  restriction  of 
the  same  role. 

Redefining  INTERNAL-COMBUSTION-ENGINB  as  a  kind  of  ENGINE  (ratfaer  than  a  GASOLINE- 
ENGINE).  and  then  redassi^g,  causes  all  of  INTERNAL-COMBUSHON-ENGINE’s  dependents  to  also  be 
reclassified,  including  fflTERNAL-COMBUSTION-POWERED-CAR.  Since  GASOLINE-ENGINE  no  longer 
subsumes  INTERNAL-COMBUSTION-ENCHNE.  the  restnoioas  for  GASOUNE-POWERED-CAR  no  longer 
subsume  those  of  INTERNAL-COMBUSnON-POWERED-CAR,  and  tbe  classifier  therefore  finds  that 
GASOLINE-POWERED-CAR  does  not  subsume  INTERNAL-COMBUSTION-POWERED-CAR.  This  is  shown  in 
figure  6-ZB. 

The  comfainatioo  of  incoosisieocy  detection  during  the  completion  phase  and  tbe  automatic  propagation  of 
classification  changes  that  occnn  during  redassificatioo  makes  KREME  a  powerfiil  and  extremely  useful  to<4  for 
knowledge  base  devetopmem  and  refinemett.  Since  the  effects  oi  redassificaiioa  are  immediately  «»«de  apparent  to 
neea  via  the  (fynaancaDy  npdatrd  gnpb  of  tbe  lattice,  they  «««**««»«  find  that  the  definitions  they 

have  provided  have  some  uninricipmed  logkaily  entailed  effects  on  their  taxonomy.  Sometimes  these  effects  are 
sniprisiog,  aitbough  cooect  Other  times,  they  lead  to  daoges  and  additions  which  make  tbe  knowledge  base  more 
compieie  and  conect 


F1giire6>2:  An  Example  of  Red«wificarion 


A.  Before  Reclassification 


B.  After  Reclassification 


6  J  Using  the  Knowledge  Integrator  to  Partition  and  Merge  Knowledge  Bases 


6J.1  Load/Merge 

Peiliaps  the  single  moat  impoitaot  use  for  the  Knowledge  Integrator  is  to  enable  orderly  merging  of 
independently  developed  knowledge  bases.  The  process  of  loading  one  knowledge  base  into  another  is  made 
somewhat  involved  by  the  need  to  merge  and/or  split  and  rename  concepts  that  have  the  same  name  in  both 
oetwoda. 


There  are  a  number  of  complex  cases  to  deal  with.  The  simplest  case  occurs  when  two  definitions  of  the  same 
concept  have  different  but  complementary  attributes.  The  KREME  merge  logic  simply  forms  the  union  of  the 
attriboies  of  both  concepts  and  edits  all  pointers  to  either  concept  so  that  they  point  to  the  new,  enriched  concept. 
(See  Figore  6*3.) 

A  somewhat  more  complex  case  occurs  when  slots  shared  by  both  concepts  are  given  different  restrictioas. 
(See  Figure  6-4.)  The  system  diooaes  the  most  specific  restriction  for  the  slot. 

If  concepts  with  the  same  name  have  properties  that  make  it  impossible  to  merge  them  —  that  is,  the  identical 
names  really  stand  for  different  concqxs  in  the  two  knowledge  bases  (6-5),  then  the  system  will  inform  the  user  of 
this  fact  and  ask  the  user  for  a  new  name  for  one  concept 

The  user  has  some  cootioi  over  this  entire  process  and  can  set  switches  which  cause  the  system  to  always 
query  when  it  finds  two  concepts  with  the  same  name,  ^ways  merge  concepts  if  it  caa  or  never  merge  concepts, 
keeping  the  knowledge  bases  distincL 


6.4  Saving  and  Partitioning  Knowledge  Bases 


Any  dme  during  the  deveiopmenc  of  a  knowledge  base,  the  user  can  save  the  entire  developing  knowledge 
base  to  a  disk  file.  TUs  is  a  usefiil  feature  when  developing  small  knowled^  bases  or  working  on  a  piece  of  a 
knowledge  base  that  will  later  be  merged  inm  a  larger  whole. 

Another  usefiil  feciliqr  is  KREME’s  SbiUty  to  piititioo  a  knowledge  base  along  nser-designared  lines  and  save 
the  panitioiis  in  distinct  files.  This  is  aoconqtiisbed  by  afiowing  the  user  to  designare  a  set  of  seed  concepts.  KREME 
wiO  then  oeaie  and  save  a  panitiao  of  the  endie  knowledge  bam,  beaed  on  the  seeds.  In  an  ovcssinqtlifed  setae,  the 
pastitioa  coiaisB  of  the  seeds,  all  specaiizatioas  of  the  seeds,  aid  all  da  concepts  tha  the  seeds  eitfam  diiectly  or 
iadisBCtly  depend  on.  This  fedlity  can  be  used  to  break  up  a  single  knowledge  bare  ino  several  ovedqpping 


6^  Using  Merge  and  Partition  to  Build  Larger  Knowledge  Bases 


Taken  togelber.  the  meifc  and  paitition  soggeat  an  approacb  that  we  think  will  prove  to  be  an 

exnemdy  powerfiil  pKadigm  in  the  building  of  very  large,  very  complex  knowledge  bases.  When  a  knowledge  base 
grows  to  a  sine  at  wtaicb  it  becomes  difficult  to  deal  with  in  its  entiiety,  the  paiddoo/isave  &cility  can  be  used  to 
divide  it  into  seveial  overiapping  logical  subcomponents,  each  of  whicfa  is  a  full  scale,  consistent  knowledge  base  in 
its  own  right 

These  mnitiple,  smaller  knowledge  bases  can  be  worked  on  independently  of  each  other  with  full  confidence 
that  the  loadei^netger  can  put  the  independeody  built  subcomponents  together  in  an  orderly,  consistent  fesbion. 

In  Hgme  6-S,  there  are  two  networks.  The  "baO”  in  Network  1  stands  for  a  concept  that  is  a  kind  of  round 
objecL  In  Network  2,  the  name  'liall''  stands  for  a  Untt  of  formal  daitce.  These  are  differenct  concepts  with 
nnmergeable  properties.  In  both  networks,  £venr  and  Object  would  be  defined  to  be  disjoint  In  this  case,  the  Merger 
would  ask  the  user  far  a  t>ew  name  for  one  of  the  concepts  and  would  keep  them  distinct. 
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Figore  60:  Example  One :  Merging  with  Nooovmiaiqung  Atttibaies 


Figare^  Two;  Ovedapping  but  Compatible  Propenies 


Machine 


Figwc^S:  Example  TtaneiUomeigeabieCoocepts 
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7.  Editing  Behavioral  Knowledge 


nUEME  eobodies  a  set  of  mechinisms  for  repieseoting  and  edttiag  bebavioral  knowledge.  Ooe  mecbaoism 
involves  beliaviois  with  frames.  Since  frames  can  also  be  associated  with  flavors,  behaviors  have  been 

implemenied  so  that  they  can  be  conqnled  into  flavor  methods. 

A  dick  of  a  mouse  button  and  the  tabular  features  window  in  the  main  concept  view  is  turned  into  the  toplevel 
befaaviw  editor.  AU  befaaviois  cnnentty  defined  for  the  concept  are  shown.  Each  has  a  name  aitd  a  type.  There  are 
three  types  of  befaaviois  cnnently  allowed;  Rules,  Procedures,  and  Methods.  Existing  behaviors  can  be  edited  or 
new  ones  defined.  A  modified  form  of  the  Symbolics"*^  flavor  examiner  can  be  accessed  to  show  various  useful 
infomuhon  about  method  combination  and  derivation. 

Methods  are  simply  flavor  methods.  Editing  a  method  throws  up  a  text  editor  window  which  can  be  interacted 
with  in  normal  editing  style  or  in  stnicture  editing  style.  Editing  or  inputhog  a  new  rule  packet  accesses  the  Rule 
Editor.  Editing  or  inputting  a  new  procedure  accesses  the  Procedure  Editor. 


7.1  Editing  Rules 

The  rule  language  used  by  KREME  is  a  language  called  FLEX  [17],  based  in  large  part  on  the  LOOPS  rale 
language.  FLEX  allows  rules  to  be  defined  in  rule  packets,  wfaicfa  organize  sets  of  rales  that  are  meant  to  be  ran 
together.  In  the  KREME  envixoament,  rule  packets  can  be  attached  to  concepts,  just  as  if  they  were  functional 
methods.  In  addition,  they  may  be  inherited  by  more  specialized  concepts.  FLEX  incorporates  a  mechanism  for 
dealing  with  unoeitainty,  baaed  on  EMYC3N  [20].  The  FLEX  runtime  environment  also  provides  an  elementary 
htstory  and  tcadng  mechanKm,  and  an  explanation  system  that  produces  pseudo-English  explanations  from  rale 
tiaoes.  For  effidency,  FLEX  also  provides  a  means  for  rule  packets  to  be  compiled  as  LISP  code,  and  ran  without 

Iha  KREME  rule  editor  ia  built  on  top  of  the  KREME  structuie  editor.  One  defines  and  edits  rales  by 
spedfyiiqt  and  fiDing  out  pottioa  of  rale  templates.  The  user  refines  these  templates  either  by  using  the  mouse  to 
copy  pnrti  of  tisiaring  rales  or  Iqr  pomting  at  slots  to  be  filled  and  typing  in  the  desired  values.  Once  a  rule-set  has 
been  developed,  the  rale  editor  provides  contmaods  to  run  packets  and  debug  them.  It  can  also  generate  traces  or 
fflle  MaBwiee  pangdaraaed  in  paeado-Eogfish.  Mechanisms  are  also  provided  fin  deleting  and  reordering  rales,  and 
loading  and  savinf  them  from  files.  The  rale  editor  is  shown  in  figure  7-1 

The  rule  edilor  is  also  tied  to  the  KREME’s  knowledge  itaegnuioa  subsystem.  At  present,  all  refisreoces  to 
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slofs  of  ftames  made  in  rales  aie  checked  for  validity  by  the  knowledge  inagrator.  If  invalid,  the  user  is  alerted  and 
may  switch,  if  necessary,  to  editing  the  assodaied  ficame.  If  the  problem  was  simply  that  he/she  named  a  non* 
mwfnt  slot,  a  valid  one  may  be  selected  Grom  a  menu.  In  the  near  fiituie,  the  kzmwledge  integrator  will  also  check 

ooss-ieGeiences  in  the  opposite  diiecnoo,  as  when  a  slot  le&iied  to  by  some  rales  is  deleted  or  changed  in  the 
frame  editor. 

KREME  at  present  edits  rales  in  the  FLEX  [17]  rale  language.  In  FLEX,  rales  come  in  rule  packets,  and  the 
KREME  Rule  Editin' edits  an  entire  packet  at  one  tune.  Rule  packets  provide  a  way  to  organize  rales. 

The  forward  <-haming  mle  packets  come  in  four  varieties,  indicating  the  type  of  control  mechanism  used  for 
role  Sring. 

•  do>l>nilc>packcts  execute  the  first  rule  whose  test  succeeds. 

•  <io>all>nile-padcets  execute  ail  rales  whose  tests  succeed. 

•  whUe-l-nilc-packets  repeatedly  test  all  rales,  filing  one,  until  no  tests  succeed. 

•  whilc-all*nilc-packets  repeatedly  fire  all  rales  whose  tests  succeed,  until  none  succeed. 

Rule  packets  are  connected  to  KREME  frame  systems  or  other  dau  contexts  by  specifying  an  access 
environment.  An  access  environment  is  an  object  that  receives  messages  dealing  with  the  accessing  of  values  for 
refinences  in  the  rules.  It  handles  all  messages  to  get  set  the  values  of  variables  and  their  confideiKes. 


7.2  The  KREME  Rule  Editor 


Rules  are  defitKd  and  edited  by  qtecifying  and  filling  out  portioos  of  rule  templates.  To  refine  these  templates 
either  use  the  moose  to  copy  parts  of  existing  rules  or  poirtt  at  slots  to  be  filled  and  type  in  the  desired  values. 

There  are  also  commands  to  run  packets  and  debug  them  and  to  generate  traces  or  rale  histories  paraphrased 
in  psendo-English,  and  delete  rales  and  leoider  rales,  and  load  and  save  rules  from  files. 


73  The  Rule  Editor  View 


Many  of  the  windows  in  the  Rnk  Editor  Mew  should  be  bmiliar  by  now.  The  complete  list  is  as  fidlows: 

L  Clefrei  CoauMod  Window  displsys  global  that  can  be  selected  by  the  nsec.  In  this 

example,  the  oier  hm  used  the  moose  to  selea  Edit  Packet.  The  user's  selection  is  highlighted. 

2.  Stale  WMnw  ifrspisys  the  name  of  the  packet,  the  netwoik  it  is  associated  with,  and  other  osefiil 

3.  Editor  Stack  Window  displays  the  names  of  the  items  reoendy  edited  and  some  infrmnation  on  their 
emreut  Slate,  bems  in  the  ediM  stack  window  can  be  selected  for  editing  with  the  mouse. 
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4.  Behavior  Command  Window  is  a  menu  of  commands  that  apply  to  Rules  and  Rule  Packets. 
{Behavior  is  another  tenn  Cor  rale  packets,  or  fiinciionai  methods  on  instances  of  concepts.) 

5.  Current  Edit  Item  Window  displays  the  item  that  has  been  selected  for  editing. 

6.  Dispay  Related  Items  Window  allows  the  user  to  view  other  rale  packets  and  scroll  through  them. 

Rules  and  paits  of  rales  can  be  copied  from  the  Scroll  Window  into  the  Cuirent  Edit  Item  Window. 

7.  Editor  Interaction  Window  displays  screen  {sompts  and  user  input  The  user’s  edits  are  made  in  this 
window  and  then  displayed  in  the  Qiirent  Edit  Itm  Window. 

8.  Related  Behaviors  Window  displays  an  index  of  other  rale  packets  that  are  related  to  the  one 
currently  being  edited.  With  the  mouse,  the  user  can  rapidly  scroll  through  this  index  and  select  a 
related  rale  packet  for  viewing  or  editing. 

To  get  into  the  Rule  editor  use  the  New  Packet  or  Edit  Packet  command  in  the  global  command  window. 

Thereafter,  the  structure  editor  can  be  used  in  much  the  same  way  the  Macro  Structure  Editor  is  used  to  edit 
concepts.  The  Rule  Structure  Command  Menu  contains  the  commands: 

•  DefliM  Behavior  is  similar  to  Classify  Concept  It  makes  the  definition  of  the  packet  permanent,  and 
allows  it  to  be  ran  or  attached  to  a  concept 

•  Similar  Behavior  •  Creates  a  packet  with  the  same  rales,  etc.  but  gives  it  a  new  name,  and  presents  it  to 

k  be  edited  to  make  it  different 

•  Kill  Behavior  •  Kills  the  definition  of  this  packet 

•  Display  Packet  •  Displays  the  packet  in  the  Display  of  Related  Items  Window. 

When  a  whole  rale  packet  is  outlined,  the  user  can  choose  to  Edit  Packet  (L:),  or  (R:)  choose  fiom  a  menu  of 
Edit  Packet.  Edit  Basis  or  Dispiay  Lisp  Form. 

Other  editing  commands  are  found  on  the  keywords  and  component  pieces  of  packets  and  rules.  For  instance, 
clicking  left  on  Rule:  places  a  new  (empty)  rale  in  the  packet  which  can  then  be  filled  out  by  clicking  on  IF  to  add 
a  new  conditioa  (conditioos  are  treated  as  part  of  a  conjunction)  or  THEN  to  add  a  new  action.  Gicking  right  gives 
a  menu  of  Add  (Empty  Rule).  Copy  One  Rule  fiom  smnewhere  else  into  this  packet,  and  Copy  Rule  Set  which 
copies  ail  of  the  rales  fiom  another  packet 

Clicking  over  Type:  gives  the  user  a  choice  of  the  standard  types  of  rale  packets,  described  above. 

Packet  Classes:  allows  the  user  to  specify  a  flavor  to  be  mixed  into  the  packet  Arguments:  and  Return 
Variables:  each  allow  the  user  to  add  a  new  one  (L:)  or  choose  fiom  a  menu  of  Add  One,  Add  Several.  Edit  and 

Replace;. 

When  a  whole  rale  is  outlined,  dkking  left  will  be  replace  the  rale  with  another  rale  that  the  user  points  at. 
Clicking  right  gives  a  menu  of  Replaoe  Rule,  Edit  Attributes  and  Delete  Rule. 

Whenever  exptessioas  appear  (after  the  woitl  Prcconditioa:,  or  as  parts  of  cooditioas  or  actioos),  the  user 
may  Replace  the  ex}»essioa  (L:),  or  choosing  fiom  a  menu  (R:)  of 

•  Replace  the  expression  with  another  one. 
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•  Edit  tbe  expieasioo  as  texL 

•  Met*  the  eqnessioa. 

•  Add  BcAm  anodier  eqnessioa  (copied  fitom  somewbeie  by  pointing). 

•  Add  After  aooifaer  ex^ession. 

•  Eeriianfe  two  expiessions  positioos. 

•  Parenthesize  a  set  of  expiessioos  together. 

•  Deparenthesize  anoqnession  into  pieces. 

•  Evataute  tbe  exptession  in  tbe  cunent  context 


7.4  Procedures  in  the  KREME  Environment 


An  obvious  weakness  of  many  knowledge  lepiesentation  languages  is  their  inability  to  handle  dedaiatively 
expressed  knowledge  about  procedures  as  partially  ordered  sequences  of  actions,  paiticulaily  if  that  knowledge  is 
represented  at  multiple  levels  of  abstraction.  Although  a  number  of  systems  have  been  developed  that  do  various 
Conns  of  planning,  [j,  13, 14, 19],  most  have  not  encoded  their  plans  in  an  entirely  declarative  or  inspectable 
ftstuon.  Cettainly  tbe  current  generation  of  expert  system  tools  does  not  provide  mechanisms  geared  to  the 
descriptioa  ot  this  kind  of  knowledge.  Although  it  is  clear  that  much  of  an  expen’s  knowledge  about  a  domain  is 
about  procedures  and  their  application,  little  work  has  been  done  on  devising  ways  to  capture  that  information 
directly. 

The  STEAMER  projea  [22]  began  to  address  tbe  issue  of  declarative  representatioos  for  procedures  in  tbe 
course  of  developing  a  mechanism  to  teach  valid  steam  plant  operating  procedures.  Tbe  representatioo  system 
developed  forthis  task  had  to  be  directly  accessible  to  tbe  students  who  were  the  system’s  users,  and  it  had  to  serve 
as  a  source  of  explanatioa  when  erton  were  made.  STEAMER  was  able  to  describe  these  procediites,  decompose 
them,  show  how  they  were  related  to  similar  prooedmes  and,  in  general,  deal  with  them  at  tbe  "knowledge  level" 
[10]  tmher  than  as  pieces  of  programs  or  rule  sets.  Ahfaougfa  tbe  syntax  of  tbe  language  was  quite  primitive,  with 
no  ptovisioas  fiir  branching  or  iteration;  the  meefamisms  for  procedural  abstractioa,  spedalraation,  and  path  or 
reference  reformulatioa  that  formed  tbe  heart  of  tbe  language  seemed  to  form  the  kernel  oi  an  extremely  useful 
Rpresentatioiial  fedlky. 

Ttaa  KREME  repwaeniation  language  femily  includes  a  descendant  of  the  STEAMER  procedure  language, 
built  using  CREMB’s  Ubnuy  of  knowledge  lepresentacian  prmiitives.  Each  KREME  procedure  has  a  name,  a 
dcser^priofi,  an  aerfon  ifam  the  proGedute  is  meant  to  aocooqtiisfa,  a  list  of  sri^,  and  a  list  of  onderiitg  coiutrointr  that 
detunuine  the  partial  oidering  of  the  siqis.  Snqn  hwre  an  actUm  and  an  ob/ea  which  names  tbe  conrepuial  class  of 
things  that  step  acts  upoiL  Procedures  are  attached  to  specific  Sanies  and  can  be  "compiled"  into  flavor  methods. 


Bach  amp  in  a  procedure  may  either  be  a  primitive  aetkn  or  another  procedure.  If  tbe  object  of  a  step  defines 


a  ptocedate  for  tbe  acdoo  of  that  step  then  this  prooedme  is  said  to  be  a  sub-ptooeduie  of  the  endosing  procedure. 
For  example,  the  ALIGN  procedure  attached  to  the  concept  SITCIION-LINE  could  have  a  step  ALIGN  <PUMP>.  If 
the  coocept  CENTRIFUGAL-PUMP,  which  is  the  objea  of  this  step  for  SUCTlON-LINEs,- defined  a  procedure  for 
the  ALIGN,  then  the  step  ALIGN  <PUMP>  could  be  expanded  into  the  steps  of  tbe  procedure  for  aligning  a 
centnfogal  pump. 

7.4.1  Procedural  Abstraction  and  Structure  Mapping 

For  knowledge  acquisidoa  purposes,  it  would  be  veiy  usefiil  if  procedures  were  represented  in  an  absoacdon 
tuemchy  like  that  for  fiames.  In  a  strong  sense,  it  seems  difficult  to  define  exactly  what  it  means  for  one  abstiaa 
procedme  to  subsume  another.  However,  fiom  an  acqnisitioo  standpoint,  much  power  can  be  gained  by  allowing 
abstract  procednies  to  Conn  upon  which  more  ^lecific  pncednies  can  be  built,  and  evenmally  providing 

tools  Cor  automatic  plan  refinement  like  those  Cound  in  NOAH  [14].  For  example,  if  you  have  some  idea  about  how 
to  grow  plants  in  general,  and  you  warn  to  grow  tomatoes,  yon  will  use  your  knowledge  about  growing  plants  in 
geneial  as  a  starting  point  Cor  leamiag  about  growing  tomatoes.  The  final  procedure  Cor  growing  tomatoes  will 
ifirind*  some  (presumably  more  detailed)  versioos  of  steps  in  (he  more  general  procedure,  and  oaay  also  include 
sttps  that  are  analogoas  to  those  used  in  growing  ocher  {dams  fiv  which  mote  detailed  knowledge  exists.^ 

The  KREME  Procedures  editor  has  a  mechanBm  Cor  building  templates  of  new  procedures  out  of  more 
abstract  procedures.  When  a  new  procedure  is  being  defined  at  a  concept,  tbe  procedural  abstraction  function 
dgtnwMinM  whether  any  of  that  conoept’s  parents  have  a  procedure  for  accom{dishing  the  same  action.  If  so,  an 
initial  procedure  temidaie  is  built  by  combining  the  ste{>s  and  consttainis  of  aO  tbe  inherited,  more  abstract 
procedures.  Tbe  {Wths  (objects)  of  tbe  siqn  ate  adjusted,  using  the  concept’s  slot  equrvaloices,  to  use  locaT  slot 
names,  as  much  as  possible.  As  yet  this  Croility  does  not  have  tbe  alnlity  to  do  detailed  reasoning  with  constraints  on 
si^n,asNOAHdoes.  We  oqiea  to  greatly  expand  this  capability  during  Phase  Two  of  tbe  {uoject 
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8.  Knowledge  Extension 


One  task  find  bf  knowiedge  enginerw  is  gecdiig  expens  to  express  geturaUzadoia  about  tbeii  domains  of 
eiqteniae.  While  macb  of  the  detailed  infixmadoa  about  paiticnlar  problems  can  be  accessed  and  lepreseoied  by 
lookmg  at  specific  examples  and  problems,  the  expen’s  abstna  classification  of  problem  types  and  the  abstract 
f^nnr9  be  uses  to  recognize  those  problem  types  ate  less  diiecdy  available.  Expetienced  knowledge  engineers  are 
often  able  to  discover  and  define  naefiil  generaiizaiioos  which  experts  perceive  as  relevant  to  tbeir  own  reasoning 
processes.  The  experts  may  then  suggest  improvements,  related  generalizations,  or  more  abstract  generalizations. 

Our  iniiial  esqiedment  in  knowledge'base  extension  in  Phase  1  has  been  the  development  of  a  frame 
generaUxation  algorithm.  Our  cnnent  generahrer  finds  potentially  useful  genetalizadoos  by  searching  for  sets  of 
concqx  fiamres  that  are  shared  by  several  unrelated  concepts. 

When  the  generaliaer  finds  a  set  of  at  least  k  feamres  shared  by  at  least  m  concepts,  where  k  and  m  are 
user-settable  parameters,  the  system  foims  the  most  specific  concept  definition  that  would  enclose  all  of  the  features 
but  would  still  be  more  general  than  any  concept  in  the  set  Since  our  simple  algorithm  has  no  other  external  nodon 
of  Tnieiesiingness’*  it  simply  disptays  this  posemial  new  caoctpt  definitioo  u>  the  user.  For  example,  given  three 
concepts  that  are  all  APUMALs  and  independently  define  the  slot  WINGS,  the  generalizer  would  suggest  forming  a 
specializatiao  of  ANIMAL  with  the  slot  WINGS,  that  these  concepts  would  all  specialize.  If  the  user  wanted  to 
introduce  this  coocepc  be  would  respond  by  naming  the  new  generalization  (e.g.,  FLYING-ANIMAL),  which  would 
then  be  classified  and  inre grated  with  the  network.  The  features  that  are  enclosed  by  this  new,  more  general 
concept,  are  antomatically  removed  fiom  each  of  the  more  specific  concepts  being  generalized. 


9.  Conclusion 


The  goal  of  ilie  BBK  Labontonea  Knowledge  Aoqnisitioa  Pnject  is  to  build  a  versatile  oqietimental 
computer  eaviioimeBt  for  devdoping  and  m«in»»ining  large  knowledge  bases.  We  are  puisoiog  this  goal  along  two 
complementary  padis.  Rnt,  we  have  coostmcted  a  Sexibie,  eseosible.  Knowledge  Representation,  Editing  and 
Modding  Enviroumeni  in  whidi  different  kinds  ie{8esentatioas  (initially  ftames,  mles,  and  procedmes)  can  be 
used.  We  are  now  using  dus  environnent  to  investigate  acquisition  strategies  for  a  variety  of  types  and 
combinations  of  knowledge  lepiesentatioas.  hi  building  aid  equipping  this  "sandbox",  we  bave  been  ad^dng  and 
expetimeoting  with  tecfaniqaes  which  we  ihitik  win  make  editing,  browsing,  and  consistency  checking  for  each  style 
of  tepresentatioa  easier  and  more  efficient,  so  ihst  knowledge  engineeis  and  subject  matter  experts  can  work 
together  to  build  sigBfficaatly  larger  and  more  deoiled  knowledge  bases  than  are  presently  practicaL 

The  second  aspect  of  our  lesearch  plso  is  the  devdopment  of  more  automatic  tools  for  knowledge  base 
reformulation  and  extenskm.  An  impoitant  part  of  tins  endeavor  is  the  discovery,  categonzatitm  and  use  of  explicit 
knowledge  about  knowledge  representations;  methods  for  viewing  different  knowledge  representations,  techniques 
for  deaoibiDg  knowledge  base  transfoanatioos  sol  extrapolations,  techniques  for  finding  and  suggesting  useful 
genenlizatioDS  in  devdopiiig  knowledge  bases,  aemi-antomatic  ptocednies  of  elidting  knowledge  fimm  experts,  and 
extensions  of  conaisieiicy  checking  techniques  to  provide  a  mechanron  for  generating  candidate  expansioos  of  a 
knowledgebase. 

We  are  attempting  to  provide  a  iaboratory  for  experimenting  with  new  representation  techniques  and  new 
tootefbrdevdflpiivk™>^lc(^t>*MS-  If  we  are  sacoessfid,  many  of  the  techniques  developed  in  our  laboratory  will 
be  adopted  by  the  comfReheosive  knowledge  acqoisitioo  and  knowledge  representation  systems  required  to  support 
the  development  and  mainienaace  of  fiknre  A1  systems. 


Appendix  A 
Loading  KREME 


A.1  Loading  KREME  from  Cassette  Tape 


Each  site  can  test  KREME  by  loading  KREME  from  tape  according  to  the  directions  in  this  Appendix  and 
then  editing  the  sample  netwoiks  ptovided  on  the  tape.  Once  KREME  has  been  loaded.  Appendix  B  provides 
instiuctioos  on  how  to  edit  and  create  knowledge  bases  using  KREME. 

KREME  requires  a  Symbolics  machine  with  Genen-7.0  already  installed  and  with  at  least  18000  Mocks  free 
in  its  FEP.  If  your  machine  has  no  tape  diive,  yon  will  have  to  read  the  tape  on  another  marhin^  that  does  have  one 
and  then  aansmit  the  bands  to  your  machine.  (See  section  A.2)  We  will  use  the  tenns  destination  machine  and  tape 
drive  machine  to  refier  to  these  two  mediines.  Note  that  yon  mnst  have  at  least  18000  blocks  hee  on  the  destination 
machine’s  FEP  as  weQ  aa  having  at  least  18000  blocks  free  on  the  FEP  of  the  machine  with  the  tape  drive. 

A.1.1  Loading  the  FEP  Files 

There  are  fimr  FEP  Hks  on  the  tape.  Your  machine  may  already  have  ioc-7>0Gl-ftt>m-Genera>7-0Joad.  If 
so,  do  not  create  a  FEP  file  for  that  file  and  do  not  load  it  from  the  tape. 

Log  in  to  the  mndiinB  and  create  three  (or  four)  FEP  files  in  the  following  way; 

CrnnUn  TU  riln  Ine-T-OGl-ezam-tSennzm-T-O.lond  1290 
Cxnntn  np  rUn  inc-BBH-fnM  Inr.  jei'inrn~7»0Gl .  lond  5600 
CsMtn  ru  ril«  lCremn-£rem-Boot7.1o»d  9580 
Cxnaftn  m  rilm  Ksumn.booe  1 

Log  out  and  halt  the  machine. 

Put  the  FEP  Hies  tape  in  the  tape  drive . 

Type  the  fbOowing  u  the  FEP; 
seaat  YUl-diefc 

(This  restore.)  Then  type 

disk  snskocn 

The  amehiaewil  dan  mkifyim’ve  done  Set  Dbk  Type.  Answer  Y'^  The  machme  then  asks  if  yon  want  to  restore 
the  HBP  flies  OB  file  tape.  In  each  cam  answer  T  and  pies  ciniafe  retum.  (If  you  already  have  the  fim  band  on  your 
tyMsm,  answer  N  tells  band.)  hi  each  case,  the  syssn  will  then  prompt 

tgr  n*  Ohk  k  MW  mS  ha  M  kma  imUMl  «•  fmr  loMl  ffMw  wimril 
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fil*  to  rostoxo? 

Aco^  the  defmlt  file  oame  by  pressing  caniage  ROiin. 

Tbe  dispUys  mimbeis  as  it  reads  finm  tfae  tape.  The  machine  then  asks  about  the  otber  files  in  turn, 

dme.  answer  Y  to  restore  tbe  file  and  then  press  caniage  return  to  accept  tbe  default  file  name. 


A.1J!  Editing  the  FEP  Files 

Now  you  must  edit  tbe  file  Kreme.boot  to  set  tfae  CHAOS  address  correctly.  To  do  tfais,  boot  tbe  macfaine 
(using  a  boot  file  otber  than  Kreme.boot)  and  edit  Kreme.boot.  (3iange  tbe  line  containing  tbe  CHAOS  address  to 
set  it  to  tfae  address  of  the  destination  You  can  get  tbe  correct  CHAOS  address  for  the  destination  macfaine 

firom  the  system  managw  or  by  looking  at  tfae  address  in  another  .boot  file  on  tfae  destination  macfaiiie. 

You  mnat  also  edit  tfae  Load  VCcracode  line  in  Kreme.boot  so  that  it  contains  tbe  number  of  tfae  microcode 
veisioa  on  tfae  host  To  'i***™*"*  that  number,  ask  tfae  sysrem  manager  or  look  at  a  .boot  file  that  boots  a  7.0  world. 

Now  log  out  and  halt  tfae  macfaine. 


A.1J  Booting  KREiVIE 

Type  tbe  following  to  tbe  FEP: 

Boot  Krema.boot 

Because  tbe  band  is  being  booted  at  a  site  other  than  tfae  site  at  wUcfa  it  was  built,  tbe  machine  will  ask  you  if 
tbe  site  is  still  BBN.  Answer  NO  and  tbe  marhin*  will  name  itself  DIS-LOCAL-HOST. 

If  tbe  machine  has  identity  ptobfems  (It  tfainki  it  is  still  at  BBN.},  tfae  simplest  way  to  deal  wiifa  them  is  to 
anping  tbe  etfaetnet  before  booting  Kieme.booL  See  your  local  system  wizard  if  you  want  a  more  elegaiu  solutioa 

Once  tfae  boot  is  complete,  you’ll  hawe  a  KREME  window  with  tfae 

prompt  Now  get  to  a  Lisp  Listtner  via 
<MXMe>Xi 

Then  log  in  with  tfae  command 

(•1 :  legla-to-s7s-boati) 

Loggiiif  in  in  ibis  way  avoids  inrerecting  with  the  BBN  sysrem  accounting  softwree.  Then  load  the  cany-tape  witb 


:  enrzylend) 

Iha  cnoY-ape  conuam  two  sanqple  KREME  netwoda,  mecb-netJisp  and  oig-aetJiq>.  You  will  have  to  choose  a 
piaoa  on  yonr  oiactaine  «D  Shire  fine  fBes. 
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You  m  now  ready  to  use  KREME  with  the  heip  of  KREME:  A  User's  Introduaion.  Try  loading  a  sample 
netwotk  ficom  one  of  tbe  files  yon  read  off  the  cany-tape. 


A.2  For  iVfacbines  with  No  Tape  Drive 


Rut,  load  the  FEP  Hies  from  tfae  tape  onto  the  tape  drive  machine  by  following  the  instnictioiis  in  section 
A.1.1.  Then  boot  that  machine,  using  a  boot  file  other  than  Kreme.boot  Then- oansmit  the  FEP  Hies  to  the 
destination  machine  by  typing  tfae  following  to  a  Lisp  Listener  (Answer  Y  when  tfae  system  asks  if  you  really  want 
to.) 

(si :  tsanarelt-bsnd  ”  £spO :  >lne-7-0Gl'-f roa-gensss-T-O .  loaul'' 

destinasiem'4nachine) 

(si : trsnsrelt-bsaid  ” £spO : >lac-bbn-£saa-lae-‘gstt*rs-7-0 .  load" 

destiitation-^itachine) 

(sl:6ssnsnlt-bsad  ”£spO :>KsaeM-£rott-bo<»e7.1osd” 

destination-macMne) 

Copy  rils  £spO:>Kssaas.boot  desn'ikin'oR-m<rcAiiie|£spO:>XraM.boon 


You  are  now  finished  using  tfae  machine  with  the  tape  dme.  You  may  delete  the  KREME  files  on  tfaat 
machine  before  going  to  the  destination  host. 


Now  coniinne  with  the  instracdoos  in  section  A.1.2. 


Appendix  B 
A  User’s  Introduction 


Abstract 

Hus  appendix  provides  an  imrodnctioa  and  preliminary  user’s  manual  for  KREME,  BBN's  i^wledge 
Representation,  Editing  and  Modeling  &iviroomenL  KR£^  has  been  engineered  to  enable  users  to  represent 
much  of  tbeir  krowledge  about  a  domain  while  mininiizing  the  classic  problems  of  knowledge  acquisitioa  when 
building  large  erqrert  systems.  The  documeats  KREME’s  component  editors  for  two  distina  representation 

langiiay^;  KREME  baffles  and  KREME  Rules.  In  older  to  maintain  internal  consistency  in  a  Frame  Knowledge 
Base,  a  problem  which  becomes  increasingly  more  complex  as  taxonmnies  get  larger,  KREME  provides  a  classifier 
to  automatically  check  subsumption  relations  between  frames.  The  KREME  editing  environment  provides  a  iiuicro- 
editing  fodlity.  for  large-scale  revisions  of  portions  of  a  knowledge  base.  The  macro  editor  allows  sets  of  operations 
to  be  perfomed  repeatedly  over  portions  of  a  knowledge  base.  Tte  required  editing  (iterations  can  be  demonstrated 
by  exrenple  and  applied  to  specified  sets  of  knowledge  structure  automatically.  The  KREME  Rule  Editor  provides 
support  for  important  rule  editing  operations. 


B.0.1  Introduction 

This  report  provides  a  user’s  manual  for  KREME,  BBN’s  Knowledge  Representation,  Editing  and  Modeling 
Orvixonment  KREME  was  designed  to  fiaciliote  the  process  of  developing  and  editing  representations  of 
knowledge  about  a  domain,  while  minimizing  the  classic  problems  of  knowledge  acquisition  that  come  up  during 
the  development  of  large  ejqrert  systems.  Knowledge  engineeis  and  subjea  matter  experts  with  some  knowledge  of 
basic  knowledge  tepresentatioa  techniques  will  find  it  easy  to  use  KREME  to  acquire,  edit,  and  view  from  multiple 
perspectives  knowledge  bases  that  ate  seveial  times  larger  than  those  found  in  most  current  systems. 


B.0J  Introducing  KREME 

KREME  is  perhaps  best  thought  of  as  a  family  of  related  editors  for  different  styles  of  knowledge 
lepteseixations.  The  cnnent  venkn  of  KREME  provides,  within  a  onifonn  environment,  a  mmber  of  special 
purpose  erfitiog  facilities  that  peonit  knowledge  to  be  rqtresented  and  viewed  in  a  variety  of  formalisms  grpropriate 
toiisnw,raiberthanfbfcingaIlkixmledgeK>beiepieseotedinasingle,onitaiy  formalism,  hi  additioo  to  a  general 
editinf  environment,  KREME  ppyridea  toob  to  do  the  kinds  of  validsiioa  and  consistency  (dirdring  so  essential 
(hiring  the  development  or  modiiicarinn  of  knowledge  bases.  As  the  size  of  knowledge  baes  grows,  and  more 
peoj^  become  involved  in  their  devekpaaent.  ibis  aspect  of  knowledge  acquisition  becomes  imeasingty  mpoitant 
In  the  Iqrbcid  or  nnIti-fiamiaUan  icpeesenatioasl  systems  tbtt  ate  becoming  prevalent  [11, 3, 21],  tecfaniqaes  mua 
be  pwvjdedfiircoaiisteiicychBdang  not  only  within  a  siniletepiesentatioaal  system,  but  between  letamd  systems. 

At  piesent,  KREME  couiains  indivkhial  editms  for  three  distiiKt  repiesentatioo  langnsges;  one  for  frames  and 
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one  tor  rales,  and  ooe  for  represeutaiioiis  of  radered  sequences  of  steps  in  operating  procedmes^. 

Frames,  (also  known  as  Concepts),  ate  the  piimaiy  way  of  esqnessing  declarative  knowledge  about  classes  or 
Utids  of  dings,  both  physical  objects  and  abstract  concepts  or  tenns.  Each  concept  or  fiame  defined  by  a  user  is 
meant  to  stand  for  a  class  of  things  of  a  paiticalar  kind.  Frames  have,  as  pait  of  their  definitioos,  a  set  of  slots, 
deaotmg^  the  different  relationthips  thattbiogs  of  that  kiod  may,  in  general,  have  with  ofoer  objects  or  concepts. 
The  names  of  slots  refer  to  rv/er,  wfaicfa  ate  independendy  defined. 

Rules  are  the  pnmaiy  way  of  expressing  knowledge  about  inferential  procedures.  The  basic  fonn  of  a  rale  is 
IF  {condition}  THEN  {action}.  Rules  are  nmmaily  clumped  together  in  ruie  packets.  A  packet  is  a  set  of  rules 
whose  coodidens  are  checked  when  trying  to  make  a  specific  dedsioo  about  sometfaiog.  In  KREME.  one  edits  a 
whole  packet  at  one  time,  rather  than  individiial  rales. 

KREME  has  a  number  of  useful  features  that  enable  it  to  make  inferences  about  the  knowledge  it  is  given. 
KREME  Frames  are  represented  in  a  hieiaicfaical  netwoik  of  more  and  more  abstract  classes.  Any  concept  below 
another  concept  in  the  netwotk  inherits  certain  attributes  from  given  information  about  concepts)  above  it;  these 
supetoidinalB  concepts  are  called  parents  of  the  subordinate  concept.  KREME’s  graphic  components  help  yon  to 
construct  networks  quickly  and  easily.  Erfiting  featnres  facilitate  adding  new  concepts  by  taking  advantage  of 
siinilarities  among  to-be-added  concepts  and  existing  ones. 

One  d  the  most  time  consuming  tasks  in  building  knowledge  bases  is  maintaining  intemal  consistency. 
Adding,  deleting  and  modifying  slots  and  parents  in  a  frame  taxonomy  may  sBact  the  subsumption  (parent/child) 
rdations  between  frames  and,  perhaps  mote  importantly,  may  change  sets  of  properties  inherited  by  meue  specific 
frames.  The  possible  consequences  of  a  change  in  one  part  of  a  network  grows  rapidly  as  taxonomies  get  la"rer. 
Consequently,  the  size  and  complexity  <rf  knowledge  bases  is  limited  by  the  extent  to  wUeb  automatic  means  are 
provided  fr>r  consistency  checking 

The  KREME  ciassifler  helps  the  user  maintain  coosisteocy  between  the  definitions  of  all  concepts  defined  in  a 
KREME  name  knowledge  base.  It  is  atvoked  whenever  a  concept  or  role  is  defined  or  redefined.  The  classifier 
first  gadiers  an  of  the  feannes  to  be  inhetiied  by  a  concept,  and  then  determines  exactly  where  the  concept  should  be 
placed  in  the  spedalization  hierarchy,  by  deducing  what  its  most  specific  parents  and  least  specific  dnldren  should 
be.  The  classifier  makes  sure  that  the  pareas  of  a  concept  indude  not  only  those  concepc  that  the  user  has  specified 
dfaectiy,  but  ail  concepts  that  desedbe  more  general  classes  that  logicaOy  inrtn«t«>  the  given  concept  as  a  subclass. 

The  KREME  etfitir^  envinotneK  provides  facilities  Cor  large-scale  revisiooi  of  potticn  of  a  frame 
knowledge  bane,  in  the  foina  of  a  macro-edUitg  fimility.  This  fiKiUty  provides  etfiting  opetatkms  that  can  be  boUt  up 
ino  fittle  "scripts",  and  then  applied  repeatedly  to  many  defiratiens.  These  "senpts”  or  macros  ate  demonstrated 
onoe,  by  eaani^  and  than  can  be  used  over  and  over  again. 
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Tbe  developmeat  of  tbe  macro  editor  was  inspired  by  onr  experiences  developing  other  expert  systems.  We 
fbund  that  over  the  life  cyde  of  such  systems,  they  inevitably  reqniae  systeoudc,  large  scale  levisioos  of  portions  of 
tbe  developed  rqnesenlatioiis.  TUs  kud  of  large-scale  levisioa  is  cansed  by  the  additioa  or  redefinition  of  a  task 
tbs  system  is  to  pet  form.  Previous  to  KREME,  sncfa  systematic  changes  to  a  knowledge  base  have  only  been 
possible  by  painstaking  piecemeal  tevision  of  each  afiected  element. 

B.OJ  Overview  of  this  manual 

Onr  general  strategy  in  this  manual  will  be  to  provide  a  brief  introduction  to  impoitant  aspects  of  tbe  system 
being  discussed  at  tbe  begitming  of  a  section  and  to  provide  detaifed  information  about  tbe  KREME  facilities  aixl 
procedures  for  using  thoee  feciliiies  later  in  tbe  section. 

We  begin  in  section  B.l  with  an  overview  of  the  KREME  environment,  providing  details  of  tbe  basic  features 
of  tbe  knowledge  editing  enviroomeat  feat  are  common  to  both  fee  KREME  fiame  and  rale  editors. 

Using  KREME  to  efet  Frame  knowledge  bases  is  discussed  extensively  in  sections  3-S.  Following  a  brief 
discussion  of  KREME  feames,  section  B2  details  (rf  tbe  KREME  system  for  representing  knowledge  in  frames  and 
editing  those  frames  are  presented.  Section  B  J  provides  a  biief  discassioa  of  tbe  frame  classifier  and  interactions 
withit  The  macro  editor  is  described  in  section  B.4. 

Section  B  J  gives  a  brief  description  of  tbe  KREME  mechamsm  for  finding  generalizations  in  KREME  Frame 
Knowledge  Bases.  The  KREME  rale  editor,  and  its  relationstaip  to  the  frame  editor  is  described  in  section  B.6.  In 
Appen^  C  we  have  provided  an  example  of  bow  to  create  new  coocqMs  using  tbe  KREME  frame  editor. 


B.l  The  Knowledge  Editor 

In  this  sectics.  we  describe  fee  oveiall  design  ttf  fee  KREME  environment,  and  give  details  of  fee  features  of 
KREME  that  are  umveoai  all  of  its  component  editois. 

B.1.1  Endows  and  Views 


We  fizR  present  some  of  fee  basic  design  features  of  KREME,  and  bow  it  appears  to  (be  user.  This  section 
wdl  deal  with  fee  appcanooe  of  fee  screen  when  using  KREME. 


At  aqr  given  time  while  oing  KREME,  you  wiQ  be  looking  at  oik  a  number  of  views  into  a  developing 
lowwledte  baw.  Each  view  ia  a  collection  of  rectangular  windows  tfaat  together  fin  up  the  Symbolics  screen.  We 
IHM*  iiieit  to  select  and  snange  fee  wtodows  in  each  view  so  tint  you  can  edit  a  particular  kind  of  knowledge 
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B.1.1.1  Views 


A  vitw  is  a  paiticolar  editiiig  perspective  on  some  aspect  of  a  knowledge  base  or  lepiesentatioa  of  an  object. 
In  KREME,  eacb  view  is  a  set  of  windows  appealing  simultaneously  on  the  Symbolics  screea  Figure  B-1  shows 
the  six  views  cnnendy  atvailafale.  They  are: 

1.  The  Top  Levef  View  is  seen  when  you  fist  oner  KREME,  and  whenever  you  are  loading  a 
previously  saved  knowledge  base. 

2.  The  Main  Concept  Editing  View  is  the  standard  view  for  editing  individual  concepts. 

3.  The  Alternate  Concept  Editing  View  contains  windows  available  in  the  Main  Concept  Editing  View 
(Slots,  Invetse  Restnctioos,  Equivalences,  Disjoint  Concepa),  but  displays  the  tables  of  concept 
features  that  are  not  nonnally  vi^le  aU  at  one  tune.  It  does  not  show  the  Concept  Graph. 

4.  The  Big  Concept  Graph  View  uses  most  of  the  screen  to  show  the  Concept  Graph,  and  does  not 
show  any  tables  of  conc^  fieatnies. 

3.  The  Macro  Stmctnre  Editor  View  provides  an  alietnaiive  method  fi>r  viewing  and  editing  individual 
concqKs.  More  impoitandy,  it  provides  a  convenient  means  of  viewing  a  number  of  concepts  at  one 
time,  copying  feamres  from  one  concept  to  another,  and  defining  and  tunning  knowledge  editing 
macros,  'nus  editing  system  is  described  in  detail  in  section  B.4. 

6.  The  Role  Editing  View  is  used  to  edit  roles,  the  relationships  that  name  slots.  It  is  much  like  the 
Main  Concept  Editing  View. 

7.  The  Rule  Editor  3^ew,  wUcfa  operates  much  like  the  macro  structure  editor,  is  used  for  editing  the 
rales  in  rule  packets. 

As  yon  can  see,  many  of  the  windows  that  appear  in  these  views  are  ‘’shared”  by  several  differem  views.  This 
is  part  of  the  basic  design  of  KREME,  to  provide  a  unifotm  styte  of  irueraction  while  focusing  on  what  is  needed  for 
editing  each  type  of  representation.  Next  we  discuss  what  these  wirxlows  are,  and  what  they  are  for. 

B.1.1.2  Component  Windows 

Figure  B-2  shows  the  Mein  Concept  Editing  l^ew  in  more  detail,  broken  down  into  its  componem  windows. 
As  you  will  see,  many  of  these  windows  appear  in  other  views,  as  welL  The  Main  Concept  Editing  View  is  the  one 
yon  will  probably  use  most  of  the  time  when  yon  are  editing  fiames.  It  contains  the  following  wirxlows  (numbers  in 
parentheses  conespond  to  the  labels  in  the  figure): 

The  global  oonunand  window  (1)  contams  commands  that  may  be  invoked  at  any  time  while  tunning 
KREME.  These  are  described  in  detail  in  section  B.1.3. 

The  edHor  stack  window  (2)  shows  the  osaes  of  the  things  being  edited  and  some  infomiation  about  their 
current  edit  sMe  (ug.,  whether  they  have  been  modified).  The  top  item  in  the  editor  stack  is  the  current 
adbor  ob/ser,  the  objea  wliicb  is  the  fbcns  of  the  cmieot  vww. 

The  state  window  p)  afavtqm  (fispi^  penment  infonnation  about  the  top  item  on  the  etbior  stack,  which  is 
called  the  cumm  editor  object.  For  concepts,  the  stare  window  contains  the  concept’s  oaffle(s),  a  line 
spodfying  whether  the  oonoept  is  primittve  and  whether  the  concept  has  been  class^M  (defined)  or  not, 
and  wtaedier  it  has  been  modeled  in  the  editor  sinoe  it  was  last  daskfled.  It  also  inclndes  lines  giving  the 
concept’s  parenre,  sod  a  rexnrel  description.  Vasnare  of  this  window  appear  whenever  yon  are  editing  a 
oonoept,  a  rale,  or  a  rate  pocket 
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llie  local  coramaiui  window  (4)  is  s  mena  of  commaods  specific  to  editmg  the  irind  of  object  displayed  in 
tfae  state  window  (tfae  cuneat  editor  object).  It  always  appeals  diieoly  above  state  window.  Wben  editing 
a  concept,  tbe  commands  m  | Classify  Concept  1.  IKillConoe^  |Ncw  Related  Conceptl  and 

IChanpe  Viewl,  tbe  last  of  wtaicb  allows  yon  to  change  to  one  of  the  other  views  available  for  editing 
concepts.  Wben  editing  objects  other  than  concepts,  a  somewhat  different  mmmantt  window  appears 
above  the  state  window,  enwmmmg  commands  usefnl  for  tbe  type  of  objea  displayed. 

The  papb  wiadew  (5)  displays  a  dynainicaily  updated  graph  of  all  of  tbe  abstracnoos  and  qtecializadons 
of  tbe  cunent  editor  object  This  view  provides  a  constant  visual  display  of  tbe  reladve  position  of  tfae 
object  being  edited  in  a  hieraicfay.  Graph  windows  often  appear  wben  yon  are  editiog  concepts  or  roles,  or. 
in  general,  objects  that  live  in  bdeiarchies.  Tbe  commands  that  ate  available  within  tbe  giapher  are 
described  in  detail  in  section  B.2.2.2. 

Tbe  table  edit  window  (6)  displays  ooe  of  a  number  of  tables  describing  a  set  of  features  that  are  part  of 
' '  tbe  definition  of  the  cunent  edit  object.  Tbe  one  displayed  in  (7)  is  tfae  slot  edit  window,  which  has  one 
line  for  each  slot  of  tbe  current  concepc  This  is  the  oonnal  table  to  see  when  editmg  a  concept,  although 
there  ate  several  otbeis,  which  an  desctibed  in  section  B.2.2.4.  Colunms  in  tbe  slots  table  show  tbe  source 
(where  it  was  inhented  from)  of  tbe  slot,  tbe  name  of  tbe  slot  (whicb  is  also  tbe  name  of  tbe  role  or  relation 
that  tbe  slot  represents),  the  slot's  value  and  number  lestxictioas,  defeult  valne,  and  a  termal  desciiptioa  of 
tbe  slot.  General  opeiatioiis  on  table  edit  windows  are  described  in  B.2.2.4. 

Tbe  table  edit  command  window  (7)  is  a  menu  containing  gfmimamfa  ebangmg  and  adding  to  the  list 
of  things  displayed  in  tbe  table  edit  wiixlow.  Tbe  contents  of  rttia  meni  changes  wtaenever  the  set  of  things 
displayed  in  the  table  edit  window  changes.  Wben  editing  slots,  commands  are  available  to  display  tfae 
■  locally  defined  slots,  displ^  the  ftall  set  of  iifoerited  slots,  add  a  new  slot,  and  kiU  all  redundant  slots  (slots 
wbiefa  are  tbe  same  as  intaexiied  ones). 

Tbe  Editor  Inter acdon  Window  (8)  is  a  Lisp  Listener  with  a  ICREME  command  interpreter  nmning.  Bodi 
ooimal  USP  eapressioos  and  KREME  commands  (like  the  ones  displayed  in  enmmand  menus)  be 
issnrd  here.  This  window  is  also  used  wben  KREME  needs  to  ask  tbe  user  for  informatioo.  This  window 
can  be  scroOed  backward  and  forward  tfatougb  a  histoiy  of  the  girrenr  session  using  tfae  scroll  bar  at  tbe 
left 

The  Motue  PommenfatioB  Window  (9)  is  always  visible  oa  Li^  mt-tiing  This  is  where  you 

look  to  see  what  tfae  nwtae  win  do  if  you  dick  one  of  its  bonoos.  (See  section  B.12.)  IT  IS  VERY 
USEFUL  -  ALWAYS  GLANCE  ATIT  WHEN  YOU  MOVE  THE  MOUSE. 

Hve  of  these  windows  are  common  to  afi  views  (except  tfae  Top  Level  View);  tbe  global  command  window, 
above,  appeao  everywhere,  induding  tbe  Top  Level  View.  The  cAor  stack  window,  tfae  state  window 
and  tfae  local  reimniand  window  appear  everywhere  but  in  tfae  Top  Level  View.  Tfae  awnsc  doenmentation 
wiadow  is  put  of  the  stenderd  Symbolics  interface,  and  so  is  always  present.  The  graph  window  is  ennendy  used 
Ibr  di^laQriiig  tfae  hienrdiies  of  concepts  and  rales  only,  aitfaoiigli,  in  tfae  fiante,  we  expea  it  wiO  be  used  for  other 
ttainpaswelL 

There  an  a  few  of  other  types  of  windows,  wfakh  win  be  «<«■«•««— where  tfaey  are  most  relevant.  Among 
these  are  tfae  stinctnre  cdUfaif  windows  that  are  used  in  tbe  Macro  Stmetnre  EAtor,  and  in  tbe  Role  Editor. 
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Using  the  Mouse 


PouMing  with  the  mouae,  and  tben  clicking  one  of  the  buttons  on  tbe  of  the  mouse  is  (be  way  viitaally  all 
ase  given  to  KREME.  This  mdodes  ail  editing  opetanons  for  browsing,  adding,  and  modifying 
Hgffnirinna,  all  coounands  to  change  what  appeais  on  the  scxeen,  and  commands  for  loading  and  saving  knowledge 
bases. 


Wherever  the  mouse  appears  on  the  screen,  something  win  happen  if  a  buaon  is  clicked.  You  can  always 
tell  y»hat  wiU  happen  by  looking  at  the  bonom  of  the  scieea  There  you  win  find  a  shoit  one-line  window  called  the 
mouse  docn mentation  window  (See  (9)  in  figure  B-2  above.)  that  says  what  each  mouse  buaon  wiU  do.  L:  is  what 
the  left  button  win  do.  L2:  teds  you  what  wiU  happen  if  the  left  button  is  clicked  twice  in  snccession.  M:,  M2:.  R: 
and  R2:  describe  the  opetanons  that  wiU  be  peifonned  by  the  middle  and  tight  buttons,  respectively.  NonnaUy,  you 
want  to  click  the  left  button  once  to  get  the  defiuik  behavioc.  The  tight  button  is  always  a  menu  of  other  opetatioos 
that  you  may  choose  ftom  instead. 

In  general,  aU  visible  references  to  an  object  cmi  be  pointed  at.  in  oider  to  view  the  object  in  more  detail.  For 
example,  a  concept  or  its  name  can  appear  as: 

1.  a  node  in  a  graph. 


2.  a  value  restriction  or  deftuilt  in  the  slot  description  table. 


3.  the  name  of  a  parent  in  the  state  window. 


4.  as  an  item  on  the  editor  stack. 

Whenever  the  mouse  is  over  a  [Command]^,  or  the  name  of  souie  ol^ect,  a  rectangle  is  drawn  around  the 
name,  and  the  of  tfas  mouse  documemation  window  changes.  Comma^  are  always  execnied  using  the  left 

ttutnmm  liMttnn  rUHring  rti»  tiMWrui  rfi«pl«y«  «nn.  niiJinw  rfnriinwwitarinn  ftw  thar  mmmml  The  light  button 

is  used  to  sec  optional  command  patameiea  beftue  executing  a  command. 

Whaaver  the  fimn  of  the  dispUy.  the  displayed  item  wig  respond  to  the  same  set  of  opnationa  when  someone 
poinB  at  ft.  and  those  opentions  will  be  specified  in  the  mouse  decumvntariou  window.  When  the  system  requires 
the  entiy  of  a  concept  name,  as  when  the  [Edit  Conce^  ;■  mm-  m«y  eiiher  type  the  name  or 


'  « 


pomt  at  aoy  visible  coooepc  name.*** 

B.l^  Comnuuid  Menus 


f  at  aa  object  appear  in  command  menus  which  ate 
aesociaied  with  puticnlar  windows  in  each  editor  v^.  Pbr  example,  the  ^obal  command  menu,  which  ^tpeais  at 
the  top  of  the  screen  in  every  KREME  view,  contains  the  following  commands:** 


•  The  I Lead  NetworkI  command  is  used  to  read  a  previously  developed  knowledge  base  imo  KREME. 
After  cHdang  on  this  command,  you  will  be  switched  to  the  Top  Level  View,  and  prompted  for  a 
filename. 


•  The  [Save  NetworkI  command  is  used  to  save  the  knowledge  base,  or  a  pmtion  of  the  knowledge  base 


that  yon  have  been  editing.  It  prompts  yon  for  a  filename  which  defiuilts  to  the  last  file  read.  (The 
defiult  is  used  if  yon  lih  <Retii^.)  Picking  tight  on  das  command  allows  you  to  save  branches  of 
networks. 


Creating  new  concepts,  roles,  and  packets  of  tales:  the 


New 

Concept 

,  New  Role  and  NewPacketl 

commands,  switch  yon  to  the  defonh  view  for  editing  an  object  of  the  ^pe  specified,  after  asking  you  to 
naoM  the  object,  and  soedfi  a  little  information  ab^  the  objea  yon  wish  to  create  on  a  pop-up  menu 
fionn.  The  INewConc^l  and  |WewRole|  commands  are  docribed  in  section  B.2  and  an  example  of 
their  use  appears  in  Appendix  C 


•  Editing  individual  coocqto,  roles,  and  rale  papers:  the  jEdltConcqitl  lEdh  Role|  and  [Edit  Packet 
commands  aD  ask  fbr  the  name  of  an  existing  object  of  the  ^tedfiM  type,  and  then  switch  to  a  view  in 
which  that  objea  can  be  preaeaied  for  editing. 

•  The  (GeneraBael  oommand  is  used  to  find  generalizations.  (See  section  B  J.) 


•  The 


command  removes  the  top  item  from  the  editor  stack*^.  (See  section  B.1.4.) 


•  The  {Resaiq  oommand  can  sometimes  be  used  to  resa  the  editor,  when  it  is  Stock  fiff  some  reason.  Use 
the  right  button  to  erase  the  cnnemly  loaded  knowledge  base. 


•The  I EarameUrtl  command  is  used  to  sa  some  top-level  psrametea  of  the  KREME  environment  Fbr 
nonaal  opetmuMis.  this  commend  should  ONLY  be  need  to  sM  the  Isngusge  syntax  need  to  read  concept 
definitions  fiom  files.  At  present  die  only  chokes  for  this  are  KREME  and  NIBX.  NIKL  mode  aOows 
KREME  to  read  definilions  fiom  files  in  NOCL  syntax. 


OKBCDl 


i('MOBILB 


•fOBMEtemwailMi 
to  Sun^  tat  oa't  ttto  ic  ey  w  I 
SdajMimaiaji.) 

ItaBMACS. 


lipMillMWdtbracoMMMdwiBdeir.  Vt 
to  wtotow  ato  aw  if  it  ■  jwi  hiddw  off  of  *• 
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When  ancwenng  a  <|Bcation  like  the  "Coooept  Hane:'*  question  that  appeaa  when  you  dick  the 
I  Edit  Concept  I  command,  you  may  eiiher  type  in  a  name  or  point  at  any  concept  name  that  aopean  on  the  screen.  If 
yon  an  onsnn  of  the  ^teOing,  yon  may  type  pan  of  the  name  and  hit  the  <COMPLJaIE>  key.  wfaicfa  will  r-atiM» 
KREME  to  tty  to  EE  ont  the  test  of  the  name.  You  can  also  hit  <COMn.ETE>  after  typing  just  the  fiist  lettea  of 
hyphenated  names.  Fv  eaample  M-0<COMPLETE>  will  expand  to  MOBILE-OBJECr  in  our  example  oetwoik. 
Also,  typiiv  the  begiaiBing  <k  a  aame  and  then  c-?  will  cause  ail  of  the  lemaining  possibilities  at  that  point  to  be 
printed.  Yon  can  then  shepfy  poiot  at  the  one  yon  want,  as  shown  below. 


□  ThM*  »r«  rh*  coi«l«tiim  at  th»  tmt  you  »<«•  tvpM: 

wchm  WMS-w-UKontnaM  mrhmicm.-(.e«  •coMmcM.-MMT  mcrKS  Macrutv-cosT 

WW-HMC-OBJECT  MCASUn  ICCHMICM.-I.n  ICOWMICM.-«llM  HOBIU-WCHIIC  WTIW-POKK 

Mass  ICCMMI1CM.-MM  MEOMIlCM.-«EMaNV  WBCTV  MOBIUE-OBJECT  MnW-VEHiaE 

nmimm-sked  MecHMicM.-OMomiM  «cMMiicM.-a>jECT  nnttv  cwg 

conctpt  imm:  NoaiLe-aejecT 

B.U.1  Local  Command  Menus 

Anytime  KRSdE  is  dfapl^ting  a  view  of  a  patticnlar  kind  of  knowledge,  the  State  Window  displays  the  most 
basic  &cts  about  the  object  being  edited.  A  command  menu  tqppeais  directly  above  the  state  window  widi  some 
basic  commands  Cor  the  type  <rf  object  di^dayed.  Fbrexamide.  when  editing  concepts,  the  following  menu  appean: 


Kill  ConcRpt  Nftw  Hnla^tna  Concept  Chunne  View 


In  these  local  command  tnemis,  one  will  always  find  the  command  that  makes  pennanent  the  defimtion  that  is 
cmrendy  being  edited  (a  Qanfly  command  for  concqxs  and  roles),  a  Kill  command  (if  applicable)  to  the 

objeo,  a  command  to  nuke  New  Belated  objects  like  the  current  one,  by  copying  the  cuxrent  definition  permitting 
yon  to  edit  it.  plus  some  misoeilaneous  other  commands. 

B.1.4  Buffers  and  the  EtUtor  Stack 

B31EME  maintiiiu  a  stack  or  list  of  the  objects  tfasc  have  been  edited,  and  constantly  displays  this  list, 
inrticeiing  wfaufa  objeos  bn«e  been  modified  and  not  redassified.  KREME  behaves  much  like  the  text  editor 
EMACS  in  tfaia  respect,  smee  it  maintsiw  a  tfistinction  between  tfaiags  that  have  been  editeel  (buffets  in  EMACS) 
and  iliiogs  that  are  dd^iwdffflesfbrEMACS).  Per  KREME,  (Afford  means  classified. 

This  fiat  of  objecu  that  hare  been  edited  in  the  entreat  KREME  session  is  displayed  in  the  Editor  Stack 
Window,  an  example  of  whicli  is  shown  below; 


Each  line  of  the  Editor  Stack  ^^^odow  starts  whh  a  character  indicating  the  kind  of  edit  objea  it  is  (C:  for 
concept.  R:  for  role,  F:  for  a  rale  packet,  which  becomes  a  function  when  ran,  an  inriication  of  the  current  edit  state 
of  the  object,  and  the  object's  name.  The  top  item  in  the  stack  (the  line  beginning  with  >)  is  the  definition  currently 
beiag  viewed  and  ediied.  The  user  is  fiee  to  modify  this  defioition  in  any  way  without  directly  affecting  the 
knowledge  baae.  The  edited  definition  is  only  made  p*™*"***  when  a  command  like  | Classify  Concept)  is  issued. 
When  defining  a  new  concept  that  has  not  yet  been  classified,  the  second  line  of  the  state  window  will  show  the 
words 

(UnelaasKlwd;  Modified] 

and  the  conesponding  (top)  line  of  the  Editor  Stack  will  contain  the  symbols  [U;M1.  This  refers  to  the  hct  that 
there  is  no  permanent  versioo  of  this  definition  yet  (Le..  it  is  unclassified).  Immediately  after  a  definition  has  been 
daiisified,  the  Slate  Window  will  diqilay 

(Classified;  Onaodlfled] 

At  this  point,  the  top  line  of  the  Editor  Stack  will  contain  the  symbols  [C;in.  If  the  object  is  then  edited,  the  word 
Unmodified  will  change  back  to  Modified. 

The  editor  stack  is  always  visibie,  providing  a  convenient  method  for  browsing  tfarougb  a  knowledge  base.  To 
make  any  definiiion  item  cnrremfy  in  the  stack  the  top  item,  point  at  it  and  click  the  left  moose  bottoa  The  objea 
win  be  displayed  in  the  same  editor  view  as  when  it  was  last  etfited.  Pointing  at  an  item  on  the  stack  and  clicking  the 
tight  botton  pops  up  a  mem  that  allows  yoo  to: 

•IMovetoTopI  -  make  the  objea  the  cunem  editor  object,  di^laying  it  in  the  view  in  which  it  was  last 
•IShow  DefInitinnI-distday  the  (LISP  fionn^  the)  obieg's  definitioo. 

•  IGraphI  •  display  a  pop-op  graph  of  the  objea 's  abstiactiofis  and  spedalizaiioas  in  a  temporary  window 
fikn  the  aoinial  gnpfaer  window. 

♦jChmifyltfae  object 

•IKsnmvo  I  the  objea  from  the  editor  stack.  withootcfansifyirM  ft.  The  top  item  on  the  editor  stack  can 
also  ba  removed  owngthelPop  Stack!  command  in  the  aiobal  command  meno. 

Tha  Idftar  Slack  W^bidow,  Eke  mom  windows  in  ECREME  views,  can  be  scrolled  if  mote  objects  have  been 
edited  than  w31  fit  on  lines  in  this  window.  When  there  ate  more  items  *♦«««  win  fit,  the  words  /More  Above]  or 
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[iiore  Below]  wiQ  afipear  io  the  line  with  cbe  words  Editor  Stack.  To  scroll,  move  tbe  mouse  into  the  window,  and 
move  it  across  the  left  edge  slowly,  until  a  double  beaded  amw  appeaa,  and  follow  the  directioas  io  tbe  mouse 
(iiwmsnurinn  window.  Alternatively,  you  can  scroll  a  line  at  a  time  by  moving  to  the  bottom  (or  top)  near  tbe 
ligtat  side  of  tbe  window  and  moviog  tbe  mouse  slowly  downward  (upward). 


B  J  Editing  Frame  Knowledge  Bases 

Tbis  section  deals  with  KREME  Frames,  attd  the  KREME  Frame  Editor.  Tbe  KREME  Frame  language  is  a 
ctose  relative  of  tbe  NIKL  language  tbai  is  tbe  defittinonal  (taxonomic)  component  part  of  fOL-TWO  and  a 
descendant  of  tbe  KL-ONE  ftame  language  [9, 15, 21].  Tbis  language  provides  an  e&cdve  way  of  defining 
conceptual  classes  wbich  live  in  a  taxonomic  ttierarchy.  The  ftames  or  concepts  yon  define  using  the  KREME 
Rame  Editor  serve  as  the  terminologicai  component  of  the  knowledge  based  system  being  developed.  That  is. 
ooocqtts  are  tbe  terms  to  be  tefoned  to  and  matxpolated  by  an  iiference  process,  pertaaps  defined  by  a  set  of 
iigln’0ice  roles  developed  usii^  the  KREME  Rule  Editor. 

BJ.1  DeBnition  of  KREME  Frames 

In  KREME.  a  ftame  is  called  a  concept.  Colkctioaa  of  concepts  are  organized  into  a  rooted  inheritance  or 
specialization  hierarchy  sometimes  tefoned  to  as  a  taxonomy  at  coocepta.  A  single  distinguished  concept,  usually 
called  THING,  serves  as  tbe  not  or  most  general  concept  at  the  Ueiaicliy.  Figuie  B-3  sbows  a  simple 
spedalizatioo  bierarcfay.  A  concept  (e.g.,  ELEPHANT  in  figure  B-3)  in  one  of  these  Inenucfaies  specializes  anottaer 
concept  (e.g..  OBIECT)  wben  the  dam  tepteseoied  by  tbe  concept  is  subswned  (is  a  subset  of)  tbe  class 
tepieseoted  by  tbe  olbec  concept  GtaphicaUy.  this  mens  tfaac  tbe  laoer  (OBJECT)  appean  an  ancestor  of  tbe  first 
(ELEPHANT). 

A  ooncqit  has  a  name,  a  textual  descriptioH,  nprinuttveness  flag,  a  list  of  defined  parents  (concepts  that  it  is 
defined  to  specialize},  a  listMilatt^^,  a.liat  of  slat  eqidvaknces,  and  a  listVof  concqxs  tbat  it  is  disjoint  from^^.  In 
KREME,  a  concept  nuy  be  snbenmed  by  mote  than  just  tbe  conoepts  that  ate  its  defined  parents.  Thus,  classified 
concurs  in  a  KREME  hietarchy  also  cnnain  distina  lists  of  those  concepts  tbat  ditectly  subsume  it  and  those 
wbich  it  disectly  subsumes  or  am  its  dteo  cfaildien. 

Tbe  lism  of  slots,  etpiivalences  and  diqoinc  concepa  are  coileciively  refened  to  as  tbe  features  of  a  concept 
If  etch  eonoept  can  be  tbongtat  of  ae  defining  a  unique  caregmy,  then  foatuies  of  the  concept  define  the  necessary 


(da£eone«pt  aooSB 
:prijBiti.v«  t 
:«p«ciaii.zM  (building) 

: slots 

((xosldoats  (a  possoa)  all  (a  paxson)) 

(<roat>doox  (a  door)  (1  1)  (a  doos))) 

: agolYalaaeas 

( (anln-aatxaneo)  (fsoat-door) ) 
tdls  jolat  (oBflca-buUdlng  apaxtaMUt-bulldlag) ) 

FigiirtBi4:  LISP  foon  of  a  KREME  tans  defiDitioa 

for  indosioa  in  thu  csKgocy.  If  t  coooept  is  not  msiked  as  primiitve,  tbe  feanues  also  constitute  the 
t-nwtpif  set  of  for  luclaiiCB  itt  that  caiegoty.  A  coooept  inherits  aQ  fieanues  firom  tiiose 

ooocqNS  above  it  in  tbe  lattice  (those  ooooeiNB  tet  sobsame  it.  and  ttaos  ate  more  general)  and  may  define  additional 
featnres  that  sene  to  <tioingiit«h  it  foosi  its  twenc  or  psteas.  Hgne  B-4  shows  the  LISP  defining  fonn  for  a 
uoncrpt.  Words  prefiiwl  bjr  cotons  deoois  the  9pe  of  fieatnre.  The  taiots  are  specified  as  a  list  of  lists  of  the  fonn 
<roU  muHg  vabit’nstrictioH  lumbmr  nmiertam  Nanes  of  concepts  in  valne  restrictions  and  defaults  are 

prefixed  bjr  s  or  ds.  Nrimber  rescictions  are  a  list  of  oninimiini  maximum>,  specifying  how  many  objects  of  tbe 
type  specified  by  the  valne  resirictiooaiay  be  related  to  an  instapce  of  this  coocqs.  NIL  here  means  "any  onmber". 

All  (rf  the  store  for  a  coooept.  when  taken  together,  fonn  a  description  of  the  tbeettribnte-valoe  pairs 

that  an  rimancr^^anret  have  for  it  to  be  considered  a  member  of  tbe  class  defined  by  that  concept.  A  slot  consists  of 

'*A  talwi  daaMiig  •  ffMide  okiMl  ia  Ihv  awid. 
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a  role  name,  a  valne  natticaoa.  a  number  restnctioa  and  an  (opdonal)  deCmlt  foim^^. 

Tbe  role  ««««»*  refea  to  a  object  called  a  roU.  Roles  in  KREME.  am  actually  distinct,  fitst  dass  objects. 
Rides  deaoflieretoloNsbenieeaoanoepa.  Avolue/iesinctionaaaslMnamedby  aroleisafiutberspecificatioaor 
i—twrtwt  of  die  range  of  the  role,  the  set  of  dungs  tbat  the  concept  that  contains  tbat  slot  can  be  related 

to.  UionoimaBy  dmnamrofsomeaibeccoooepc  Hie  ddeute  of  the  mie  is  a^genetal  cfaancrenzatioo  of  tbe  set  of 
pdas  may  use  tbisiole  to  relare  objects  to  otber  objects.  Put  aoodier  way,  it  is  tbe  most  geneiai  class  of  things 
can  use  this  role  a  the  name  of  a  slot.  As  fint-dass  objects,  loles  fium  their  own  distioa  taxonomy,  tooted  at 
most  general  possible  role,  usuafly  called  *R£LATION*.  Hguie  B*5  shows  a  poitioo  of  a  simple  role 
nomy. 


rrelatiOfT) 


Figure  B>5:  A  Simple  Role  Taxonomy 

A  lole  definitioa  has  a  ibbnc,  a  description,  a  list  of  roles  that  it  jpedollxex.  a  domain  and  a  range.  In  a  fonnal 
sense,  a  role  is  a  two-piaoe  relaiiaa  tbat  maps  insonoes  of  concepts  in  its  domain  onto  sets  of  instances  in  its  range. 
Tbe  domain  of  a  nde  is  the  most  general  concept  at  which  the  rote  makes  sense.  Tbat  is,  it  specifies  the  class  of 
dungs  for  which  the  role  can  name  asiot.  Tbe  range  of  a  role  specifies  the  general  class  of  concepts  tbat  can  serve 
as  vafaMS  in  slots  defined  using  that  role.  All  concepia  fiDiog  dots  whose  naeae  is  a  given  role  must  be  eiemems  of 
the  range  of  that  role. 

Each  slot  at  a  concept  has  as  pan  of  its  definition  a  vobie  restriction,  which  is  tbe  class  of  allowed  values  for 
dat  slot  Tbe  value  lestiiainn  mot  always  be  a  shb-daas  of  the  range  of  that  role,  and  a  snixiass  of  the  value 
resttictioas  defined  for  that  role  at  all  concepts  subsuming  the  one  lesthcted.  Value  lesttictioiis  most  be  defined 
concepts. 

Sims  also  a  number  restriction  that  specifies  the  minimum  and  maximum  (if  any)  nomber  of  things 
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that  may  be  related  by  the  role  to  in«taiir«  of  the  coocept.  For  example,  if  aU  el^bacis  have  four  legs.  the 
concqit  ELEPHANT  might  be  defined  to  restrict  the  role  LEGS  to  Exactly  4  ELEPHANT^LEGs**  A  number 
Rsiticiioa  mnst  be  at  least  as  specific  as  all  of  the  mimber  restdctioiis  fat  the  same  role,  at  any  of  the  concept’s 
paienB.  A  number  resadctioo  of  Exactly  1  (min  »  max  >  1)  is  more  qiedfic  then  a  mnnher  restrictioa  of  At  most  2 
(frg„  min  a  0.  max  s  2). 

EqiuvaUnces  describe  slots  that  by  defbudoH  refisr  to  the  same  entities.  They  are  defined  as  pairs  of  paths 
whose  refierents  are  the  same  concept  A  path  is  a  list  of  role  names,  the  head  (first)  of  which  is  the  name  of  a  slot  at 
the  coocept  defining  the  equivalence.  Each  subsequetu  slot  name  in  a  path  must  be  a  valid  slot  in  the  coocept  that  is 
the  valne  restriction  of  the  previous  slot  in  the  path.  The  referem  of  a  path  is  the  value  of  the  last  slot  in  the  chain. 
Hgute  B-d  shows  a  simple  example  of  an  equivalence. 


Tbe  SUCTION  of  the  PUMP  is  eqnivaleu  to  die 
INLET  of  the  SUCTION  VALVE  of  the  PUMP. 


Figure  A  Slot  Equivalence 

Concepts  marked  as  primitive  (sometimes  refiened  to  as  Natural  Kinds)  have  no  complete  set  of  sufficient 
condilions.  For  example,  an  ELEPHANT  must,  by  necessity,  be  a  MAMMAL,  but  without  an  exhaustive  list  of  the 
aBrifantrs  that  distingBiah  it  finm  other  mammals,  it  must  be  tepresetxed  as  a  primitive  concept  WHITE 
ELEPHANT,  on  the  other  hand,  might  be  completely  described  by  stating  that  it  is  a  specialization  of  ELEPHANT, 
where  the  tide  COLOR  was  restricted  to  WHITE. 

KREME  Ftames  permit  slots  to  have  default  values  as  well  as  value  restrictions.  If  present  the  default  must 
be  the  deactiptian  of  some  concept  wfaiefa  satisfies  the  tesirictioos  on  the  role  at  that  conc^  The  defuilt  is  used  as 
a  shit  filler  tor  instances  of  a  concept  that  do  not  specify  a  valiie  for  the  slot  at  instantiation  time.  Defaults  are 
inheriiedftoiB  the  most  specific  parem  at  which  they  are  defined. 


*^^l»heiaw  ii— 4.— r»4t  VitwRairtriiitmBLBPHANT-LEa). 

MMBf.HlLianBaMaMIN-a.  MAX-NIL ■  te mm  w  MAX-iiyMiy.  A ■■■>»  rwwiriiiw  ip»ci6wl  ■  « mmsI. Munbw n  hw 
MBt-MAX-n.  N»MM>wwMmdoM(NR-NlL)BWMMlN-O.MAX-i<yiwiy. 
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B.2^  Using  the  Frame  Editor 


Tbe  KREME  hwie  ethtor  has  five  views,  as  shown  in  figiue  B>1,  the  Main  Concept  Editing  View,  the 
Altcrnata  CdacapC  EdHtog  \^ew,  tbe  Big  Graph  View,  and  the  Macro  Strnctnre  Editor  View.  Roles,  wtdcta  are 
also  past  of  the  KREME  Fame  language,  an  edited  with  tbe  Role  Editing  View. 

In  fids  section,  we  win  cover  tbe  details  of  tbe  editing  operatioos  availabie  in  the  first  three  of  these  views. 
Tbe  Role  Editing  View  is  covered  in  Section  B.2.4.  Tbe  Macro  Strnctnre  Editor  is  covered  in  secaoa  B.4. 

B.2,2.1  Editing  in  the  Main  Concept  Editing  View 

Normally,  when  one  creates  a  new  concept  or  edits  a  concept  for  the  first  time,  KREME  makes  that  concept 
the  top  concept  on  the  Editor  Stack,  and  switches  to  di^lay  the  Main  Concept  Editing  View.  There,  KREME 
dispiays  tbe  concept  as  it  exists  at  that  time. 

ngure  B*7  shows  bow  the  graph  window  immediately  displays  all  of  tbe  abstracnoos  and  specializations  of 
tbe  concqtt  being  edited,  the  state  window  shows  its  name,  whether  it  is  primitive  or  not,  its  edit  state  (classified  or 
not,  modified  m  not),  its  parents,  and  a  textnai  descnpiiotL  The  table  window  simultaneously  displays  all  of  tbe 
concept’s  locally  defined  slots. 

In  the  remaiiider  of  this  section,  we  wtQ  cover  all  of  the  operatioos  available  by  pointing  at  aU  of  tbe  difierent 
parts  of  tfaia  frame  editing  view,  as  well  as  describing  in  detail  tire  woikings  of  tire  Grapher  and  Table  Editing 
Windows,  which  also  appear  in  many  other  contexB  in  the  KREME  environment.  We  begin  with  tire  Grapher. 

B.2.2.2  The  Grapher 

KREME  is  equipped  with  a  poweifiil,  general  gta{tiiing  fadluy  that  rapidly  draws  lattices  of  nodes  and  links. 
Its  main  nse  is  to  provide  a  dynamically  updated  display  of  a  concept  or  role  and  its  place  in  tire  specialization  or 
inbeiitaace  Ueraichy.  When  editing  a  concept  in  tbe  Main  Concept  Editing  View  or  tire  Big  Concept  Graph 
Mew,  or  when  ediiir^  a  role,  KREME  automaticaUy  dtsplays  all  of  that  objea’s  abstractions  and  spedalizatioos, 
wtih  more  afasttaht  o^ects  to  tire  left,  and  moK  spedaUzed  otqects  to  tire  light  of  tire  current  editor  object. 

As  shown  above  in  fig^  B>7,  tire  graph  is  tmtially  centered  on  tire  cutreui.  editor  object,  wfaicb  appears  as  a 
Mack  node  with  while  letiem.  AU  other  objects  appear  as  nodes  with  a  white  background.  Objects  that  are  defined 
as  prMcfveaseiixIicjaBd  by  thicker  box  edges.  Nodes  tim  have  been  modified  (edited  but  not  redassified)  appear 
as  nodes  whh  a  giey  badkgrauniL 


Pming  the  Graph 

An  inpoctant  feature  of  the  gtapher  is  that  it  can  dis|tiay  graphs  that  are  much  larger  than  tire  window  through 
which  they  am  viewed  If  you  went  to  see  s  part  of  tire  netwodt  that  ii  off  tbe  screen,  pdm  with  tire  mouse  at  some 
point  on  the  paph  window  not  containing  a  node,  and  bold  the  left  button  down.  The  moose  cursor  wiU  change 
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F1far*B>7:  Tbe  Mw  Concept  Editing  View 
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Editor  Initracfion  Pans 


from  an  aiiow  to  the  shape  of  a  band.  While  still  bolding  the  left  mouse  button  down,  drag  tte  mouse  in  the 
you  wish  the  graph  to  move,  and  it  will  move  smoothly  as  though  you  were  pushing  a  piece  of  paper  that 
was  only  partly  visible  in  the  space  provided  by  the  graph  window. 


Monnal  Panning  Speed  Panning 

Figure  Panning  the  Graph 

Another  way  to  pan  more  quickly,  called  speed  panning,  is  accomplished  with  the  middle  mouse  button. 
Again,  place  the  mouse  over  an  unoccupied  spot  on  the  graph  window,  and  push  the  middle  button.  A  small  square 
with  a  dot  in  it  will  appear.  This  is  the  "joy  stick".  While  still  holding  the  middle  button  down,  move  it  a  little  bit 
off  from  the  center  of  the  box,  and  the  graph  will  begin  to  move  slowly  in  the  direction  yon  have  moved.  The 
fuitber  away  from  the  center  of  the  box  you  go,  the  faster  the  graph  will  move. 

The  Overview  Graph 

Now,  dick  the  right  buaon  once  over  an  empty  pan  of  the  graph  window. 


The  Graph  Operations  menu,  shown  below,  in  figure  B>9,  will  appear. 


Graph  Qperefiong 

hardcopy 
font  menu 
find  node 
tovgr^teM 
orientation 
speed  pan 
redraw  oraph 


Figure  B>9:  The  Graph  Operaitoas  menu 


We  win  discuss  the  other  grapher  options  below,  in  section  322.2.  For  now,  dkk  [overview  and  a 
miniatiire  version  of  the  fiill  lattice  wifi  appear  on  in  a  black  region  in  the  upper  left  comer  of  the  graph  window. 
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Tbis  shows  the  full  oetwodc  displayed  in  the  graph  window,  but  with  tiny  nodes  and  lidcs.  The  visible  region 
of  the  gnph  will  be  indicated  by  a  white  rectangle  inside  the  black  one.  Now  pan  with  the  mouse  over  the  main 
graph  window,  and  the  white  rectangle  will  fdlow  your  movements. 


Now,  move  the  moose  into  the  overview  window.  The  nodes  on  the  overview  graph  will  be  highlighted  by  a 
box  as  you  pass  over  them,  just  as  they  are  in  the  main  graph  window.  All  of  the  mouse  operations  available  on 
nodes  in  the  main  window  win  also  work  on  nodes  in  this  window.  (These  operations  wiU  be  covered  in  section 
B2J2.2.)  The  name  of  the  node  is  indiicated  in  the  mouse  docnmenution  wiiutow. 


The  overview  window  also  can  be  used  to  pan  the  main  graph  window.  Pointing  Geft  button)  to  a  spot  on  the 
overview  that  contains  no  node,  causes  the  main  graph  to  pan  so  that  the  upper  left  comer  is  at  that  spot  You  can 
also  hold  and  drag  the  mouse,  and  the  graph  will  follow  you. 

To  turn  the  overview  off,  simply  bring  op  the  Graph  Operations  menu,  and  click  the  command  |  overview  | 

agaia 


The  Graph  Opcratioas  Menu 


The  other  options  in  the  Graph  Operations  menu  show  in  figure  B>9  are: 


-  Sends  a  copy  of  the  fiiU  graph  of  the  latuce  to  the  printer. 


I  •  Allows  you  to  chose  a  change  to  the  foot  style  and  size  of  characters  used  for  nodes  on 
die  graph.  Smaller  fonts  are  useful  to  see  mme  of  large  networks  at  once. 


•Iflndood^  •  Prompts  for  (he  nsme  of  an  object  on  the  graph,  and  centers  dm  node  on  the  graph 
window.  It  also  diaws  a  code  around  the  node  so  that  you  can  find  it  more  easily.  The  code 
disappeais  as  soon  as  (be  graph  is  panned. 

•[overrleun  -  Switches  the  overview  gn^ih  between  visible  and  invisible.  The  overview  graph  was 
diacuased  above  in  section  B.2.2.2. 


•lorientatiioiiil  •  Switches  the  osientatioa  ^  the  graph.  Ndmally,  the  lattice  is  drawn  fiom  left  to  tight 
This  command  win  came  the  graph  to  be  rediawn  ftom  the  top  of  the  screen  down,  and  vice  veisa. 


Has  command  pops  up  the  speed  pacniog  box  without  having  to  hdd  down  the  niou*re 
button.  In  this  mode,  clkkiag  any  moose  button  win  make  it  go  aw:^. 
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•  Redraws  the  ameat  graph. 


The  Graph  Node  .Command  Mem 

Nonnally.  die  KRBME  Grapher  only  displays  the  abstnehoas  and  spedalizadons  of  the  cunent  editor  object, 
rather  thaa  tiyiiig  to  dispUy  all  of  what  is  potentially  a.  veiy  large  lattice.  This  was  done  intentionally,  sinr** 
KREME  was  designed  to  wodc  with  ve/y  targe  knowledge  bases.  Occasionally,  however,  one  wishes  to  see  mote 
(or  less)  than  KREME  nonnally  displays  on  such  graphs.  The  Grapher  provides  a  imniber  of  options  to  enable  users 
to  tailor  what  is  displayed  to  their  needs. 

Whenever  the  moose  is  over  a  node  cn  a  graph,  the  moose  doenmentatioa  window  shows  the  name  of  the 
node,  followed  by: 

Z,:Idin  this  aodo.  MiSxmph  Rolneiwoa  R:Moatt  o£  editing  Options 


rtifiring  the  left  moose  bottoo  KREME  to  make  the  objea  pointed  to  the  top  editor  stack  item.  If  you 
are  looking  at  a  concept  graph,  yon  will  then  be  viewing  the  concept  pointed  to,  a  graph  of  its  abstiaciioas  and 
spedalizatioos,  and  a  table  of  is  slots.  This  is  an  extremely  convenient  way  of  browsing  through  large  concept 
networks  quickly,  and  focosing  on  difEerent  pordoos  of  soch  a  network.  If,  however,  yoo  wish  to  continue  editing 
the  concept  you  are  conendy  viewing,  but  see  m<ae  (or  less)  of  the  network  around  that  concept  or  some  other 
concept  on  the  same  graph,  yoo  can  use  the  graph  relatives  menn  found  by  clicking  the  middle  mouse  button  over 
any  graph  node. 


The  graph  relatives  mcrai,  exposed  by  diddng  the  middle  button  over  a  node,  contains  the  following 
commands: 


•IGraph  Parents|- causes  all  abstractioos  of  the  node  clicked  on  to  be  added  to  the  displayed  graph. 
•[Graph  Children  |- c»ises  all  spedalizatiota  of  the  node  clicked  on  to  be  added  to  the  displayed  graph. 


•  I  Hide  Chadrenj- causes  all  be  removed  ftom  the  graph,  unless 

they  are  also  children  of  some  other  node. 


•[Hide  Node  and  Oiildrcnl- causes  the  node  dicked  on  and  its  children  to  be  removed  from  the  graph. 


Edithig  a  Network  fhmi  a  Graph 


Clicking  the  right  bottoo  over  a  gnph  node  caoes  yet  another  meno  of  options  to  be  exposed. 


graph  edit  options 


.20 


This  menn  oooiains  the  following  options  for  concepts: 

•[Show  PefhntionI  •  This  option  causes  the  texmal  (LISP)  Cmm  of  the  concept’s  definition  to  be 
displayed  over  the  Graph  Window. 


vt  ralM,  Ob  r«la  tnfh  iSII  aftlMi  ■MBippnn, 


farroW  a«xp««« 
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•IKiil  Coacqitt-  lUs  caoses  tbs  ccxicept  poinwrf  to  to  be  temoved  from  tbe  knowledge  base.  It  bas  the 
same  elBsa  as  the  KOI  Concept  mmmanri  in  the  local  command  menu  window,  except  that  it  woiks 
when  yon  am  not  cnnently  editing  ibe  ccnoqst  yon  wish  to  ldlL^‘ 

•I  Rename  Concept  I  •  This  command  prompts  yon  for  a  new  name  for  tbe  concqit  poinied  to,  and 
immediatety  reptaces  aU  lefnenoes  to  that  name  with  the  new  name  throughoot  tbe  knowledge  base. 

(See  (be  Rwame  Concept  command  in  section  B.2.23.)^ 

•IPeieteParentl-Tliia  command  prompts  far  the  name  of  a  patent  (which  you  may  give  by  pointing  to 
the  giapb)  and  then  deletes  that  patent  horn  the  list  of  defined  patents  of  the  concept  initially  pointed  to. 

It  also  switches  KREME  to  editing  tbe  concept  modified,  so  that  it  can  then  be  leclasafied. 

•lAddParSl-  This  command  also  immpts  te  a  patent,  adds  the  concept  named  to  tbe  list  of  defined 
patents  of  the  concept,  and  switches  to  editing  the  modified  concept. 

•ISpBce  Oat  Parentl  <  This  command  prompts  for  a  patent,  and  removes  that  patent  from  the  list  of 
defined  patena  of  the  concept,  t^lacing  it  with  (Aot  concept’s  patents.  Again,  the  editor  is  switched  to 
a  view  of  the  modified  cono^ 

B,2  Editing  in  the  State  Window 

As  described  in  section  B.1.1.2,  tbe  state  window  of  tbe  Main  Concept  Editing  View  displays  basic 
infbnnation  about  the  concept  conentiy  being  edited. 

'C:  [C;U]  OBJECT 


The  top  line  displays  tbe  name  of  tbe  concept,  and  any  synonyms  or  alternate  names  for  that  concept  Tbe 
name  of  the  concept  can  be  changed  by  clicking  on  the  word  |  Concept;  and  entering  a  new  name. 

The  second  line  of  tbe  display  shows  whether  the  concept  is  defined  as  primitive  or  not,  and  whether  tbe 
concqx  has  been  classified  ot  modified  since  classification.  Qiriring  on  the  word  [Primitiveri  causes  the  concept 
to  be  marked  primitive  if  it  was  not,  and  vice  versa. 

The  third  liiK  dispUys  tbe  both  the  d&rcr  and  defined  parena  of  tbe  concept,  after  tbe  word  Spcdalizes:. 
D^ned  parents  are  concepts  that  the  user  specifies  as  abstractions  of  tbe  concept  Direa  parents  are  concepts  that 
may  or  may  not  have  been  defined  a  pareas  of  the  caneiu  one,  but  have  been  determined  by  the  classifier  to 
tnbsnme  tbe  dass  denoted  by  this  concept  and  not  have  any  specializations  that  also  subsume  this  cotKept.  On  the 
Qmoept  Graph,  the  direct  paretss  of  a  concept  ate  the  ones  with  direct  links  to  it 

is  M  KB  caaiMBd  wiilaMi  oa  liH  rat*  pafh  «Ml  •ftlMM 
**na»e«— di»c«BrimilUI»lgan»r»itaf»efc«Biam>— — . 
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This  SptdattMs:  list  staookl  be  read  as  follows:  Concepts  dat  are  nnmaitwl  are  both  defined  parents  and 
direct  parents.  Concepts  tbat  are  dcAned  parents  but  not  direct  parents  are  prefixed  by  a  Concepts  that  are 
direct  parents  but  not  defined  parents  are  prefixed  by  a 


To  add  a  parent  to  tbe  set  of  defined  parents  of  the  concept,  sinqily  elide  tbe  left  button  over  the  woid 
I  and  9pe  (or  point  to)  the  name  of  a  concept  that  yon  wish  to  make  a  parent  of  this  concepL  To 
otherwise  alter  the  set  of  defined  parents  ,  dick  the  tigbt  button  on  the  word  ISpedalix^f  Yon  will  be  presented 


with  a  menu  of  the  following  options: 


Add  Defined  Parent  |  -  Prompts  for  the  name  of  a  concept  to  make  a  defined  parent 


•iPeiete  Parents  which  aren’t  direct  I-  Allows  you  to  poiot  to  defined  parents  that  are  not  direct  parents 
(Le.,  those  prefixed  by  a  and  have  them  removed  ftom  the  list  of  this  concept’s  defined  parents. 

•  IMake  direct  parents  defined  parental  •  This  command  causes  od  of  the  diiect  parents  to  become 
defined  as  parents  of  the  conoepL 


The  fourth  and  subsequent  lines  of  tbe  state  window  display  the  user-specified  textual  description  of  tbe 
concept,  which  provide  a  means  of  documentation.  To  enter  a  new  description,  click  on  the  wotd|  Description:  [and 

you  will  be  prompted  for  lines  of  text  until  you  enter  a  biaok  line  by  just  hitting  <R£TtJItN>  or  <£N1>>. 


BJL2.4  Editing  in  the  Table  Edit  Window 

Normally,  tbe  table  edit  window  in  Main  Concept  \i1cw  Oaplsys  the  set  of  |  Local  SlotsI  of  the  concept,  tbat 

is,  tboee  slots  which  are  defined  locally  by  this  coneqx  and  not  inherited  ftom  above.  The  cohsnns  in  tbe  table  are 
labeled  "Defined  by",  "Rote",  "Number  Rcstrktion",  "Value  Restrktion”,  "Defiuilt",  and  "Description". 


Clicking  (with  the  left  moose  button)  on  the  command  [AH  Slots(  in  tbe  table  edit  conunand  window  causes 
KREME  to  dispUy  both  local  and  inbeiiied  slots.  In  this  display,  local  slots  are  indicated  by  the  woid  "LOCAL*  in 
the  "Defined  by"  column  of  tbe  taUe.  Sloa  inherited  from  a  parent  show  the  name  tbat  parent.  Slots  formed  by 
combating  the  vaine  restrictions  andAtr  number  lestiictiOQS  of  several  parents  are  indicated  by  the  word 
"CLASSIFIER*.  When  the  table  window  is  dhplsying  all  of  tbe  concept’s  slots,  you  can  return  to  viewing  just  the 
local  ones  by  efidring  the  commindrLocdl  SlotsT 


Hill  I  TV 


"VOCAC 

*tOCA|.« 

*tOCAC* 

"LOCAL" 

•LOCAL" 

"LOCAL* 

•LOCAL* 
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Whenever  the  Table  Edit  M^ndow  shows  slots  of  the  ament  concf^  you  can  edit  those  dots  or  add  new 
«niit  To  change  the  shx  name,  vafaie  eestrictioo.  nwmber  testnction,  d^mlt,  or  desaipiioo  of  a  slot,  simply  dick 
the  left  mouse  button  over  the  thing  to  be  changed,  and  yon  will  be  prompted  fora  teplacemenL  For  all  but  oomber 
,  the  light  button  will  pop  up  a  menu  that  includes  the  commands  |<iluuige|  the  pan  of  the  slot  pointed  to. 


[Shew  DeflnftionI  of  the  concept  or  role  pointed  to,  |Edit  Deflnition|  of  that  concept  or  role,  or  pop  a  |  Graph  |  of 
is  abanactitWB  and  «|weiaiiyariniia  When  pointiag  to  the  slot  name,  in  the  colunm  labeled  "Role",  you  can  also 
IRenaam  RdeL  that  is.  change  the  name  of  the  role,  and  all  lefeiences  to  it  in  the  knowledge  base. 


When  the  mouse  is  over  a  line  in  the  slot  table,  and  the  enme  line  is  endided  by  a  box.  the  tight  mouse  button 
can  be  used  to  get  a  menu  of  fP^e  Slott  ( 


I  to  another  concept,  and  [Move  Slot|  to  another  concept.  For 
the  last  two.  KREME  prompts  for  the  name  for  the  concept  to  move  or  copy  the  slot  to. 


At  any  >«»»*,  when  you  have  started  to  make  a  change  and  me  being  prompted  for  a  replacement  value,  you 
can  hit  the  <ABORT>  key  to  leave  things  as  they  were. 


Adding  New  Slots 


Whenever  the  slots  taUe  window  is  visible,  as  in  the  Main  Concept  Editing  View,  you  can  add  new  local 
skx  definitions.  A  new  slot  is  added  to  the  slots  of  the  concept  with  the  |AddSaot|  command.  When  this 


cntunaad  is  issued,  the  system  prompts  for  a  role  name,  a  value  lesmctioa.  a  number  lesaicdon  and  a  defimlt  form. 
Any  of  these  items  cau  be  eoceted  by  typing  (mby  pmtaing  to  the  desired  name  or  form  if  it  is  visible. 


If  a  role  or  concept  named  in  a  role  restiictioa  or  defoult  does  not  exist  the  system  win  ofo  to  make  one  with 
the  name  given,  and  proceed  to  pop  up  the  defining  ftmn  for  that  objecL  (See  section  B.2.2J.)  When  you  ate 
fintiihed  filling  out  the  Conn,  click  [xjDeffne,  and  KREME  wifi  continue  to  ask  Cor  the  rest  of  the  new  slot’s  foatuies. 


When  you  have  adding  atxl  modifying  the  slots  of  a  concept,  you  should  always  make  the  changes 


petmanetn  with  the  IClassifr  Conceptl  command.  For  an  exteixled  tieairoent  of  this  commaod,  see  section  B.3, 
below. 


Modifying  the  Table  Edit  Window 


The  appearance  of  Table  Edit  Windows  can  be  modified  in  several  ways.  The  tables  ate  scroUaUe  in  both  the 
upKiown  and  left-right  duecdons.  Simply  "bump”  the  mouse  against  the  top  or  left  sides  of  the  wirxiow  until  the 
double  beaded  arrow  appears  and  firllow  the  directioas  in  the  mouse  documentation  window. 

If  you  do  not  wish  to  see  some  cofamms  of  the  table,  they  can  be  selectively  removed  by  clicking  the  middle 
buBon  in  the  firm  duftayiag  the  colmnn  headings  (when  the  double  arrow  is  eor  showing).  Yon  will  be  presented 
whh  a  metm  on  which  you  can  tick  off  the  cohntms  that  you  wish  to  see  and  not  When  you  ate  satisfied  click  the 
baxmeifcad{z)Doli.  Ifyoo  do  not  wish  to  go  through  widi  the  change,  click  [x]Abort 
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Chaagiiig  die  Coatcnts  of  tht  Table  Window 


Since  Itaeie  is  not  enoogb  iDom  in  (he  Main  Coooqn  Bditing  View  to  display  all  of  a  concept’s  defining 
at  one  time,  the  coniefa  of  the  Table  Edit  IXfindow  can  be  changed  to  display  those  other  fiMnues.  To  do 
this,  yon  most  use  the  monae  to  find  the  table  window  contents  mrmi  This  menu  is  available  wbeiever  there  is 
ooihiiv  else  under  the  moose  while  stiD  inskie  the  talte  window.  Yon  will  know  you  have  found  it  because  the 
moose  docnmcntatfam  window  will  show  the  woids: 

K:  Chamgo  thn  eostnaha  of  this  hablo. 


The  best  places  to  look  axe  to  the  tight  of  the  "Desa-iption'’  column,  and  anywhere  in  the  liiK  of  column 
(when  the  double  headed  anow  is  nor  showing).  Clicidng  the  tight  bnnon.  you  will  see  the  following 
menu  options: 

•ISIotsI- Displays  the  table  of  das  concept’s  slots,  as  descnbed  above. 

•Ilnverse  Restriction^  •  Displays  a  taUe,  essentially  tike  the  slots  table,  but  of  all  of  the  slots  displayed 
are  slots  of  other  concepts  that  use  the  cunexa  cooc^  as  their  value  restriction.  This  table  is  useful 
when  you  are  tiacing  references  to  a  concept  in  other  concepts.  When  this  table  is  displayed,  the  table 
edit  command  wfaidow  will  be  empty.  Some  of  the  editing  options  described  for  the  slots  table  will 
not  work  here. 


•ISjotEgeivalen^l-  This  table  displays  the  slot  equivalences  of  the  current  editor  concept  This  table 
has  only  thtee  oolumns,  "Defined  by”,  "Path  1”  and  "Path  2”.  'The  two  paths  are  designated  as 
denoting  the  same  object  Since  atm  equivalences  can  be  inherited,  their  source  is  also  indjcated  in  the 
table,  in  the  column  "Defined  by".  Whert  to  table  is  visible,  the  tole  edit  command  window  will 
show  the  commands  |  Local  Eqnivalencest  |AII  Equrvalencest  and  |Add  Equivalent  The  first  two 
just  change  which  equivaknoes  are  diqilayed.  Hie  last  prompts  fi>r  two  slot  paths  that  should  be  made 
equivaient 


•IDlsjohit  Conceptsl  •  This  table  is  just  a  one  column  list  of  all  of  the  concepts  that  ate  defined  to  be 


disjoint  Etom  the  one  currently  being  edited, 
window  will  di^day  the  commands 


I  AH  Dfajoint  Classes  t. 


When  to  taMe  is  visible,  the  Table  Edit  Command 


Add  Dfajoint  Classt  [Local  Disjoint  aasnal  and 


B,2,2,5  Operations  on  Concepts 

Making  new  concepts  and  roles 


Clicking  on  the _ 

make  a  new  concept  or  role. 


orjNew  Rote) command  in  the  glohal  command 


is  the  simplest  way  to 


When  making  a  new  concept,  KREME  will  {nompt  for  the  name  of  the  new  concept,  and  then  a  pop-up  foim 
will  appear  that  looks  aa  follows. 


ll«.  eonceot  flIPCPflf T-CflPPIEP _ 

Description: 

Prinitive^:  Yes  No 
lndivido«t~:  rc5  Mo 
Direct  perents;  (WCSSEL) 

rtet  ine  sod  further  edit  [J 


yoa  may  ^)ecify  a  desoqxiQa  of  the  oew  coocept,  whether  it  is  piimitive  or  not.  whether  it  is  aa 
iadivkliial  (a  special  kitid  of  pninitive  class  that  has  only  one  member,  like  the  color  RED),  and  a  list  of  its  direct 
dafined  parents,  whiefa  must  be  a  list  enclosed  in  paientbeses. 

When  yon  are  done,  click  either  the  box  labeled  {z|Dcfiiie  or  [xjDeAiM  and  further  edit  if  you  wish  to  make 
the  oew  concept  the  cuireot  editor  objea  in  order  to  do  things  like  adding  new  slots  before  classifying  it 

Another  way  to  make  a  new  concept,  one  that  is  similar  to  another  concept,  is  to  use  the 
|New  Related  Concew  command  in  the  local  command  menu.  This  command  allows  you  to  choose  horn  a 
pop-up  menu  whether  you  want  to  make  a  new  concept  diat  is  similar  to  the  currently  visible  concept  or  to  some 
other  concept,  a  spedalizaiioo  of  the  current  concept  or  some  other  concept,  or  a  specialization  of  several  concepts. 


Nevi  concMt  related  to  nBCHlriE - 

Bimilar  to  some-  o^er  eweepU  ] 
Specialization  ot  MACHINE 
Specialization  of  some  other  concept 


If  you  choose  to  make  the  concept  similar  to  some  existing  concept,  KREME  makes  up  a  concept  defimnon 
that  is  identical  to  the  concept  you  specify,  but  with  the  new  name,  and  then  allows  you  to  edit  it  to  make  it 
somewhat  diSRcnL  If  you  choose  to  make  the  concept  a  specialization  of  some  existing  concept,  KREME 
automatically  makes  the  parent  of  the  new  concept  be  the  one  you  are  spedalizmg. 

The  command  (New  Related  Rolel  in  the  local  command  window  of  the  Role  Editing  View  wotks 
essenriall/  the  same  way. 

Killing  Concepts 

fTtanging  the  name  of  a  concept  or  role  directly  afEeca  the  netwodc.  The  name  of  the  concept  dotation,  as 
weR  as  d»  name  of  tbs  coirespoii&igclaiufied  concept  Qfdiere  is  one),  is  changed.  AH  poimea  to  the  conc^  (as 
a  parent  of  other  concepts,  in  valoe  leatraaiona,  as  the  domain  or  range  of  loies  etc.,) « antomaiicaQy  updated  with 
tilt  new  Dane  bodi  in  the  classified  netwofk  and  in  all  editor  buflbis. 

The  I  tan  CenesptI  ctmmand  slices  a  concept  out  of  the  taxonomy.  With  this  command,  the  children  of  a 
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coocqx  win  bt  oowieciBd  to  an  of  its  parens.  Any  concept  tbat  used  to  define  tbe  concept  as  a  parent  is 
Mwia—ifiwrf  If  tbe  concept  was  used  as  a  valne  restricdon.  the  editor  txies  to  find  an  appio{niaie  paren  to  substitute 
for  the  killed  concept  dus  attempt  is  not  always  successful,  user  inieiactioa  is  sometimes  required. 


To  delete  any  defined  slots  wtioae  defioitioas  are  die  same  as  the  infaeiited  definitions,  click  on  tbe 


I  Kill  Redundant  Slotsl  command  in  tbe  sloes  table  command  menu  window,  above  tbe  the  slots  table  edit 


window.  This  operadon  alteis  tbe  definidoo  of  the  concept,  but  not  its  classificadon  or  comfdeted  descripdon. 
(Qassificadoa  will  be  discussed  in  detail  in  section  B.3  below.) 


B.2  J  Alternate  Concept  Views 


Three  other  views  are  currently  defined  for  concepts,  and  one  view  roles.  Two  coneqK  views  display 
windows  not  oormally  visible  in  tbe  Main  Concept  Editing  View  (see  figure  B-10),  while  the  third  is  tbe  Macro 
Structure  Editor  to  be  discussed  in  secdoo  B.4  below. 


To  change  to  an  aliemaie  concept  view,  use  the  [Change  View]  command  in  the  local  command  menu 


window  above  the  state  window.  Qicfcing  on  jSlota  and  Equrvalencesj  brings  up  the  first  window  in  figure  B>10. 
This  view  shows  an  enlar^  slots  table  edit  window,  tbe  dlajoiiit  concepts  window,  and  the  slot  equivalences 
window  together,  along  with  the  cdltar  stack  window,  the  state  window,  and  associated  command  menu  windows. 


Qicfcing  on  [Large  Concept  Graphj  shows  tbe  second  view  of  figure  B>10.  This  view  uses  most  of  tbe 
screen  to  display  tbe  spedalizatioa  hreraictay,  together  with  the  State  Window  and  Editor  Stack  Window. 


B.2.4  Editing  Roles 


The  Role  Editbig  View  (figure  B-11)  appean  whenever  tbe  Edit  Role]  or  [  New  Rolel  commands  are  issued 
from  the  glohel  command  menu,  when  pointing  at  the  name  of  a  tote  appearing  as  the  name  of  aslot,  or  pointing  at 
a  previously  edited  role  appearing  in  tbe  Bdtor  Stack. 


The  Role  Etfitlng  View  ooiwins  a  window  showing  a  graph  of  tbe  role  specialization  network,  highlighting 
tbe  currently  visiUe  rale,  another  displaying  a  list  of  tbe  concepts  that  testcia  the  rale,  and  tbe  role  state  window. 
Tbe  local  coasnuuid  menn  window  tor  roles  <««*««««  tbe  ctwnmmt<c 


•IClam^  Cmreiri  Roit[  -  dasiuliw  or  makes  permanem  a  new  or  changed  role  definiiiog  -inserting  it 

iiao  the  rale  hientefay,  and  cfaectang  that  any  concepts  that  use  that  rale  ra  name  a  slot  satisfy  tbe 
domain  and  rsugecomtiainis  specified. 

•IWmr  Reiamd  Rolel  -  Creams  a  new  rale  that  is  similar  to  or  a  specialization  of  tbe  current  (or  some 
odam)ml».  fttopemdoo  is  analogous  to  thefWewRelamdCoiicept|comman± 
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FlfMTvmiO:  AlieiiHtive  Concept  Editiog  Viewc 
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U^er  Input  Herring 


•ICoocepts  Ptfiniag  Slot»|  •  Oanges  the  window  showing  the  list  of  concepts  using  this  role  as  a  slot 
name  to  incinde  only  ones  that  loeaUy  dtfint  those  slots,  as  opposed  to  inheriting  them. 

•ICoacepla  With3o5|- (Tanges  the  same  window  to  display  ail  coocepa  that  have  a  slot  with  das  role 
name. 


B.2.4.1  Editing  in  the  Role  State  Window 


A  similar  set  of  operaiioui  exisB  for  editing  die  basic  foanires  of  roles  in  the  role  state  window  as  exists  in 
the  concept  state  window. 

•  |Role:|  invokes  a  command  to  change  the  tide's  name,  and  all  lefoteoces  to  it  in  slots. 

•  I  Primitiv«l  toggles  the  primitiveness  of  the  role. 


•iDilferentiates;)  allows  you  to  add  a  patent  to  the  role.  CStcking  the  right  button  over  the  word 


Differentiates; I  brings  op  the  mem  of  |  Add  Defined  Parent).  [Delete  Parents  which  aren't  direct 


and  [Make  direct  parents  defined  parentsL  all  of  which  work  as  described  for  concepts  in  secdon 
BJ2.2.3. 


•  Domain:  or 


LZIl'Ui 


prompts  for  a  replaoemeot  value  for  the  defined  domain  cr  range  of  the  role. 


respecdvdy.  (Ticking  the  right  butlon  on  one  of  these  words  gives  you  a  menu  of  t^doos  including 
thorn  discMsed  above  and,  when  appropriate: 

♦[Defliied  dontaitt  eqnal  compared  valuej  which  makes  the  defingH  domain  be  the  same  as  the 

ckus^tad  domain,  which  is  iiaetsectioa  (really  the  conjuncdoa)  of  the  role’s  defined  domain  and 
the  domaia  of  its  perent  role(s)  (if  any). 


« iDeflned  range  eqaalqMBpatedvalnel  which  makes  the  defined  range  be  the  same  as  the 
ciass^Ud  range. 


B  J  The  KREME  ClassiHer 


B.3.1  Introducing  the  Classifier 

One  of  the  moat  tnie  comaming  tasks  in  boildiiig  knowledge  bases  is  maintaining  internal  consistency. 
Adding,  deleting  and  modi^riiig  slra  and  parents  in  a  fiame  taxonomy  may  affect  tbe  subsompdon  teladons 
between  frames  and,  petfaapa  moK  ampoftandy,  may  alter  tbe  sea  of  properties  inbenied  by  mote  specific  frames. 
The  poasibie  ooneqneooea  of  a  change  in  one  pait  of  a  network  grows  rapidly  as  taxonomies  get  larger. 
Gmarqueotly,  the  siaB  and  conpladty  of  knowledge  bases  is  fimiied  by  tbe  extent  to  wfaicb  antomatic  means  ate 
provided  for  oonaaten^  chackiDg. 

The  KREME  ctoi^ferfaelpa  the  naer  maintain  coosiateocy  between  tbe  definidoos  of  all  conoepe  defined  in  a 
KREME  Pranw  kaarwledga  baae.  R  amt  be  ntvoked  (by  the  user)  whenever  a  concept  or  role  ia  defined  or 
mdathad.  Iha  dataller  fiat  gadamaB  of  the  feataies  to  be  infaetiied  by  a  concept,  and  then  deietmines  exactly 
where  the  emmept  shoaM  ptectid  m  tpgrialiwainii  hitwawhy 


foiumkm  I  $hu 

i  rfo  i«ifci 

tntsnutf  I  oftJtCl 


User  Ilerrln9 


Tbe  cIjiWifiiiT  should  always  be  invoked  once  yoa  an  satisfied  with  a  concept  or  role’s  definitioo.  It  is  the 
nwjriianiitni  by  winch  KREME  makes  the  new  definidon  pennanent,  and  insera  it  into  the  knowledge  base.  To 
classify  a  defimtion,  click  on  tbe  IClasaify  Concept!  command,  in  tbe  local  command  menu  window  (tbe 
IQaasify  Itoiel  command  if  yon  am  edhing  a  role)  or  toe  the  |Claaaify|  command  in  tbe  pop-up  menu  available  by 
dkking  tbe  dgin  button  on  some  object  in  the  Editor  Stack  Window.  KREME  will  detetmine  tbe  completed 
d^mtioH  (a  definiiion  plus  all  its  efiSscdve,  inbeiited  featuns)  of  tbe  object  and  use  that  infonnation  to  detetmine 
tbe  objea’s  lelative  location  in  tbe  subsumption  Ueraicfay  of  all  previously  classified  definitions  by  deducing  what 
tbe  new  concept’s  most  specific  pannts  and  least  specific  childxen  am.  Tbe  system  also  chedra  to  see  if  other 
concepts  or  roles  need  to  be  reclassified  because  of  tbe  new  definition.  If  so,  KREME  will  continue  until  it  has 
mclassified  every  objea  that  might  have  been  affected. 

Afler  a  coooepc  has  been  classified  or  reclassified,  KREME  immediately  displays  tbe  effects  of  classifying  tbe 
defimtion.  ^Hsibie  absttaction-tgircialiTarioo  gr^ths  am  redrawn,  showing  bow  the  arrangement  of  parent-child 
relationships  throughout  the  taxonomy  has  changed.  On  these  graphs,  links  added  or  deleted  by  tbe  classifier  will 
seem  to  appear  or  dis^ipear  instantaneously.  For  example,  the  classifier  makes  sure  that  the  direct  parents  of  a 
concept  includes  ooly  defined  pareno  with  no  childien  that  subsnme  tbe  concept^. 

B.3.1.1  Completion 

Completion  refers  to  tbe  basic  inheritance  mechanism  used  by  tbe  KREME  classifier  to  install  all  inhexited 
features  of  a  concept  in  its  intemal  descxiptian.  Given  a  set  of  defined  parents  and  a  set  of  defined  features,  tbe 
completiou  algorithm  determines  the  fiiil.  logically  entailed  set  of  features  at  a  coocept  (or  role).  Compleaoa  always 
occurs  before  dassificatioo  or  redissification  of  a  role  or  concept 

A  concept  inheriis  aQ  the  value  and  number  restrictions  on  every  slot  fiom  all  of  its  parents.  For  each 
nnkioefy  named  slot  at  each  concept,  a  smgle  uumber  and  value  restrictioo  is  created  that  conjunctively  combmes  all 
restnctions  for  that  slot  from  tbe  local  definition  of  tbe  slot  and  the  definitions  at  every  parent.  Tbe  effective  value 
restriction  is  either  tbe  single  most  specific  of  all  the  value  restrictions  for  that  role  at  tbe  concept,  or  a  conjunction 
of  all  (tf  them,  if  no  single  one  is  subsumed  by  afi  the  otbers.  The  e^rotive  onmber  restriction  for  each  slot  is 
sunilaifydettnniiird  by  intersecting  the  number  ranges  in  all  of  three’s  inherited  number  restrictions. 

Complicationi  arise  when  more  ihsn  one  parent  concept  defines  the  same  slot,  and  no  restriction  on  that  slot  is 
mote  specialized  than  all  of  the  otbeis.  Hgure  B-12  illustraies  one  way  this  can  occur;  when  the  most  specific  value 
restrictioo  is  inbetiied  fiom  one  pmnt  (ANIMAL)  and  tbe  most  specific  onmber  restriction  is  inherited  from 
apother  patent  (4-LlMBED-THING)  to  farm  the  lesttkaioo  of  LIMBS  at  4-LIMBED- ANIMAL 

Hgnm  B*t3  shows  another  exaople  of  completion  in  which  the  resnlting  vaine  restrictioo  most  logically  be 
the  coquDCtion  of  several  coocepo.  Since  ANIMAL-WTTH-LECS  is  an  ANIMAL,  and  a  THING-WTTH-LEGS  all 


an-Y  1 — J - ■> - ■  « |--r-|TT  ■«—  — ■ — mr  Tht  -rmcipt  t  ttkim  rnirr.  -ir*  -m-r  ly  direct  linka 

witeadwfnek 
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Flgnre  B*12:  Inbehdng  Number  and  Value  Resoictmos 

of  its  LIMBS  must  be  both  ORGANIC-LIMBs  and  LEGs.  If  the  concept  ORGANIC-LEG,  specializing  both 
ORGANIC-LIMB  and  LEG,  exisis  when  ANIMAL- WITH-LEGS  is  classified  for  the  first  dme,  the  classiSer  will 
find  it  and  make  it  the  value  tesoicdon  of  the  slot  LEGS  at  ANIMAL-WITH-LEGS.  If  it  does  not  exist,  the 
classifier  stops  and  asks  if  the  user  would  like  to  define  it 


Figure  B-13:  Combining  Value  Restiictioiis 

bi  genenL  whenever  a  value  lestnctioo  can  only  be  defined  as  a  coojunctioo  of  several  concepts,  KREME 
aUm  to  fbnn  a  concept  lepteseiuing  the  coqunction.  and  asks  for  a  name  for  the  new  concept  These  new 
ooncepis,  called  CMEETs,  must  be  named  by  the  user. 
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B.3.1.2  Interactions  with  the  Classifier 

As  indicated  above,  tfae  KREME  classifier  sometimes  needs  to  fonn  new  concepts  in  order  to  satisfy  some 
logical  leladonstatp  or  determine  the  eSscdve  lestdcnoo  on  the  range  of  a  role.  These  classifier  required 
conjunctioas  are  called  CMEETs. 

CMEETs  ate  formed  when  the  classifier  is  trying  to  determine  the  e^ctive  value  restriction  for  a  slot,  or  the 
effectivedomainor  tange  of  arole.  At  snch  tunes,  KREME  enforces  the  restrictions  that  the  concept  oriole  inherits 
from  above,  while  incorporating  the  locally  defined  coostraint  KREME  requires  that  the  value  restriction  of  any 
slot  is  at  least  as  specific  as  all  of  the  inbeiited  value  restrictions  on  that  slot  (and  the  range  of  the  role  naming  the 
slot).  Technically,  the  effixtive  restriction  on  a  slot  is  always  the  conjuncdon  of  (e.g.,  tfae  class  denoting  tfae 
intersection  of)  all  inherited  lestricrions  and  the  locally  defined  restriction  on  the  slot.  Thus,  if  one  defined  tfae 
concept  FROG  as  an  ANIMAL* WITH-LEGS,  and  defined  tfae  slot  LEGS  to  be  restricted  to  (a  FROG*LEG)  without 
defining  FR(Xj*LEG  as  both  a  LIMB  and  ORGANiC-LEG,  KREME  would  ask  to  make  a  CMEET  that  combined 
all  of  these  classes.  Since  you  probably  would  want  to  change  the  definirion  of  FROG-LEG  rather  than  create  a  new 
term,  KREME  allows  you  to  say  this,  rather  than  create  the  new  concept. 

The  thiid  major  case  in  which  CMEETs  are  formed  is  when  a  value  restriction  is  not  subsumed  by  the  defined 
range  of  the  role  that  names  the  slot  Thus,  if  the  role  ENGINE-OF  had  range  (AN  ENGINE)  and  the  slot  ENGINE 
on  CAR  was  defined  with  value  restriction  (A  CAR-MOTOR),  which  had  (perhaps  accidentally)  not  been  defined  as 
a  kiod  of  ENGINE,  KREME  would  ask  if  you  wanted  to  define  the  CMEET  (AND*  (A  CAR-MOTOR)  (AN 
ENGINE)).  Again,  you  {mtbably  want  to  must  make  CAR-MOTOR  a  kind  of  ENGINE. 

Lastly,  OIEETs  are  formed  when  determining  the  effective  domains  and  ranges  of  roles  that  are  cbildier  of 
otfaer  roles.  However,  it  only  happens  if  you  define  a  role  to  specialize  another  role,  and  are  not  careful  to  make  sure 
that  the  domain  and  range  you  specify  are  subsumed  by  tfae  domain  and  range  of  the  parent,  respectively.  In  any 
case,  KREME  will  let  you  know,  and  enable  you  to  fix  it.  one  way  or  another. 

B.3.1.3  Options  when  asked  to  form  CMEETs 

While  forming  the  appropriate  conjunction  ia  tfae  logically  correct  thing  to  do  to  ensure  consistencyiof  the 
kixiwledge  base  as  then  defined,  it  often  turns  out  (as  suggested  in  the  preceding  secrion)  that  the  conjunction 
suggested  by  the  classifier  is  needed  because  one  of  the  concepts  to  be  conjoined  bas  been  improperly  defined.  In 
particular,  a  CMEET  condirion  most  frequently  arises  because  the  concept  used  as  the  value  restriction  of  a  role  in 
tfae  concept  being  classified  is  not  subsumed  by  the  restricrion  for  the  same  role  at  a  higfaer  concept,  and  tfae 
restriction  must  logically  satisfy  both  constraints.  This  is  illustrated  in  figure  B- 14.  The  figure  shows  TWO-PORT- 
TANK  defined  as  both  a  TANK  and  a  TWO-PORT-DEVICE.  Each  of  those  concepts  restricts  the  role  INLET- 
VALVE.  The  classifier  finds  that  the  restriction  for  slot  INLET-VALVE  at  TWO-PORT-TANK  mnst  be  both  a 
VALVE  and  a  STOP-VALVE,  given  tfae  restiictioos  of  that  slot  at  TWO-PORT-TANK’s  parents.  Since  STOP- 
VALVE  was  not  defined  as  a  kind  of  VALVE,  the  conjunction  is  not  the  single  concept  STOP- VALVE,  and  so  the 
classifier  asks  if  it  should  create  a  new  concept,  the  CMEET  of  VALVE  and  STOP- VALVE. 
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Figure  B>14:  Discovedag  a  missing  subsumer  by  a  CME£T  check. 


Whenever  the  KREME  classifier  lequires  that  a  CMEET  be  fonned.  it  stops  and  queries  the  user,  explains  the 
sioiadoo  and  requests  a  name  for  the  concept  to  be  formed  for  the  conjunction,  and  enumerates  several  alternative 
opdoos,  as  shown  below. 

Yon  have  several  opdons  at  this  pant  If  all  of  the  concepts  are  defined  conectly,  aixl  the  proposed  CMEET 
conectty  describes  the  required  restrictioo,  simply  enter  a  name  for  the  new  coiKept  and  classificatioo  will 
continues.  If  the  problem  really  lies  with  an  existing  definition,  as  is  the  case  with  VALVE  and  STOP-VALVE,  you 
can  choose  an  alternative  course  of  actioa  rather  than  introducing  a  useless  new  concept  Most  often,  the  correct 
actton  is  to  alter  the  subsompdon  relatioos  between  the  named  coiKepts  so  that  one  of  them  is  subsumed  by  the 
others.  This  is  done  sitttply  by  naming  one  of  the  concepts  to  be  conjoined  instead  of  giving  a  irew  name.  In  our 
exairtple,  the  user  would  simply  type  STOP-VALVE,  in  respoirse  to  the  query.  The  classifier  would  then  make 
STOP-VALVE  a  kiod  of  VALVE  and  condniM  classifying  TWO-PORT-TANK,  resulting  in  the  relations  shown  in 
figure  B-16. 

This  iruetacttoo  effectively  allows  a  user  to  correct  an  oversight  in  a  previously  defined  concept’s  definition  at 
the  point  the  error  is  detected  by  the  classifier. 

If  fonrrirtg  the  CMEET  is  the  afqrropriate  acdoo,  simply  emer  a  name  for  die  new  concept;  classification  will 
contiine.  If  you  do  not  intend  to  form  this  new  concept,  name  the  more  specific  coocepL  This  alters  the 
sobsumptioa  leladoas  between  the  concepts  to  be  conjoined,  so  that  one  of  them  is  subsumed  by  the  others. 
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Altering  STOP- VALVE  to  correct  a  CMEET  error. 
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Fisnrc  B>16:  Afier  interaction  with  the  classifier. 


B.4  The  Macro  and  Structure  Editor 

B.4.1  Macro  Editing  of  Knowledge  Bases:  Background 

Qoiie  fieqnendy  choices  about  tepiesencations  made  early  on  in  the  development  of  a  Knowledge  Base  proves 
to  be  inappiopiiaie,  and  massive  editing  is  required  to  convert  the  accumulated  representatioa  base.  A  macro  facility 
makes  these  dedsioos  easier  to  reverse,  and  therefore,  less  disruptive  and  costly. 

In  Older  to  express  and  package  conceptually  clear  reformulations  of  cotKepts  and  other  representations,  as 
well  as  develop  rrew  concepts  from  old  ones,  KREME  provides  a  macro  facility  for  reformulations.  This  fuility  can 
be  expressed  as  sequences  of  standard,  low-level  editing  operations  which  define  editing  macros  to  be  applied  to  sets 
of  concept  definitions  by  giving  a  single  example. 

B.4.2  The  Macro  and  Structure  Editor  View  v 

One  of  the  views  available  when  editing  concepts  in  KREME  is  the  Macro  Structure  Editor  View.  This 
view  (See  figure  B-17.)  provirks  i>n  alternative  set  of  display  and  editing  fOT  concept  definitions.  The  view 

provides  two  windows  for  the  display  of  stylized  defining  forms  for  concepts.  The  current  structure  edit  window 
displays  the  definition  of  the  current  editor  object  concept  (the  top  item  on  the  editor  stack).  The  display  structure 
window  is  available  for  the  display  of  any  manber  of  other  concepts.  Any  concept  whicfa  is  visible  in  either  window 
can  be  ediiecl.  and  fisa cures  can  be  copied  from  one  ccxtrept  to  anattmr  by  pointing.  Both  windows  can  be  scrolled  to 
view  additional  definidons  or  parts  of  definitioos. 

As  in  the  ooimal  KREME  concept  edmng  views,  both  inbeiited  and  defined  features  can  be  displayed. 


i 


♦ 


rtidcing  the  mouse  over  tbe  keyword  iodicadag  each  feamie  class  in  a  coocepc’s  definidon  (c.g.,  | Abstractions:!, 
ISIotet  lEquivaknceszt  etc.)  toggles  the  display  of  that  component  set  of  features  between  defined  and  all 
inherited  features  oi  that  type. 


Tbere  is  a  rnetm  of  commands  for  displaying  and  editing  definitions  in  these  windows.  Itincludes: 


Add  Structarel  •  Qiddng  dns  command  followed  by  one  of  the  concept  feature  keywords 


Abstractioas:,  Slots:,  Equivalences:,  Disjoint  Classes:  causes  KREME  to  prompt  for  a  new  objea  of 
that  type.  Tbe  new  item  can  be  typed  in  or  copied  Grom  some  other  visible  concept’s  definition  by 
pointing. 


•IChange  Stmctnrel  •  Clicking  this  command  and  then  the  item  to  be  replaced  (a  parent,  slot  name, 

value  restriciioo,  number  resinction,  default,  an  equivalence  or  component  path,  or  a  disjoiru  class) 
causes  KREME  to  ask  for  an  appropriate  replacemem.  Again  tbe  new  value  may  be  typed  in  or  pointed 
to. 


•  [Delete  Structare|  .  Clickiog  this  command  and  then  the  item  to  be  deleted  removes  it  from  tbe 


concept's  definitiotL 

•  [Display  Structure  -  Pointing  at  this  command  and  then  any  visible  concept  name  or  definition  places 
the  defitadon  of  the  concept  in  tbe  Display  Structure  Window. 

•  [Clear  Displ^ •  Removes  aU  definitioos  from  the  display  window. 


Arguments  (if  any)  to  these  commands  may  be  described  by  pointing  or  typing.  For  example,  to  delete  a  slot, 
dick  onIDelete  Shructurel  and  tbe  display  of  the  slot  to  be  deleted.  To  change  (that  is,  replace)  a  structure,  point  in 
succession  at  the[ClianKe  Structnre[  command,  the  item  to  be  replaced,  and  tbe  thing  to  replace  it  with. 


In  many  cases,  [Delete  Stmctnrel  and  [ Change  Stnicture[  can  also  be  invoked  simply  by  pointing  at  the 


structure  to  be  replaced,  and  diddng  tbe  left  mouse  button.  Delete  Suucture  is  ofren  available  on  tbe  menu  of  tight 
button  optioos  (check  tbe  mouse  documentation  window. 


Individual  concepts  can  be  deleted  from  tbe  display  window  by  pointing  at  them  and  clicking  tbe  rigis  button. 


Tbe  [Edk  Concept  [  comr.tand  is  used  to  change  what  is  displayed  in  tbe  current  edit  udndow.  Editing  a  new 
concept  moves  the  old  edit  concept  to  the  bottom  of  tbe  display  window. 


B.4  J  Developing  Macro  Editing  Procedures 

Qobally  available  commands  for  defining  new  cotarepts  and  specializing  old  concepts  by  copying  their 
definitiona  together  with  the  commandi  in  tbe  Structure  Editor’s  main  menu  provide  an  extremely  flexible 
enviroament  in  which  to  define  and  sptxify  modificatioiis  of  concepts  with  respect  to  other  defined  concepts. 
>nztiially  all  knowledge  editing  operations  can  be  done  by  a  sequence  of  poittting  steps  using  the  current  edit 
window  and  the  displqr  window.  TUs  combioatioo  of  editing  features  and  mouse-based  editor  inteiactioQ  style 
provides  an  extremely  versatile  errvirooment  for  the  description,  by  example,  of  a  large  class  of  editing  macros. 
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The  windows  on  tlie  bottom  of  tbe  Macro  and  Stnicture  Editor  Scieen  are  used  for  defioing.  editing,  and 
numing  inacxos  composed  of  structure  editing  opendoos. 


To  define  a  macro,  first  edit  a  concept  £or  wtncfa  the  macro  will  make  sense,  and  then  click  on  the 
I  Define  Macrol  command  from  tbe  mem  below  the  structure  edidog  windows. 


Undl  tbe  macro  definidon  is  tenninated  by  clicking  on  [Define  Macrol  again,  all  editing  and  concept  display 
opeiadoos  peifonned  will  be  recoided  as  st^  in  tbe  macro,  aird  displayed  in  the  lower  left  window  of  the  screen  in 
Fjtglith.  Specific  objects  mendoned  as  arguments  will  be  replaced  by  references  to  macro  items,  which  are 
nambeied  and  ^ipear  in  a  list  in  tbe  lower  dgbt  window. 


B.4.4  Changing  features  into  concepts:  A  Sample  Macro 

.  It  is  easiest  to  understand  how  to  use  tbe  macro  facility  by  looking  at  an  example. 

In  developing  frame  representadons,  tbe  choice  must  often  be  made  between  defining  a  slot  to  oenote  that  tbe 
concept  has  some  attnbute  (e.g.,  defioing  RED-CAR  as  a  CAR  with  slot  COLOR-OF  lestdcted  to  (A  RED)},  and 
defining  the  concept  by  making  it  specialize  another  concept  that  stands  for  the  class  of  objects  with  that  attribute 
(eg.,  defining  RED-CAR  as  a  CAR  and  a  RED-OBJECT.) 

When  this  choice  has  been  made  in  a  way  that  later  seems  awkward  or  inappropriate,  given  the  use  that  tbe 
concept  has  in  tbe  knowledge-based  system  under  development,  it  can  be  veiy  time  consuming  to  change.  With 
KREME,  however,  macros  can  be  defined  that  can  make  tbe  change  in  either  direcdon. 

We  illustrate  this  kind  of  restroctming  operadon  with  a  macro  that  provides  a  way  ol  forming  a  con<rept 
RED-OBJECT  denoting  tbe  set  of  all  objects  widi  tbe  role  restricdon  COLOR-OF  «  RED.  Tbe  macro  makes  us:  of 
the  classifier  to  find  all  such  classes  and  make  them  children  of  RED-OBJECT,  and  then  remove  the  COLOR-  OF 
slots  from  all  classes  that  were  found  to  denote  red  objects.  Tins  macro  can  be  used  on  all  colors  defined  in  tbe 
knowledge  base,  to  completely  eliminaie  references  to  COLOR-OF  slots. 

Tbe  following  sequence  of  steps,  aQ  of  which  were  specified,  by  exampie,  using  operadons  available  in  tbe 
Macro  Structure  Editing  View,  accomplisbes  this  task.  Hgure  B-t8  shows  this  macro’s  steps. 

Step  1  cieaies  tbe  concept  RED-OBJECT  as  follows;  Fist,  the  command  [New  Related  Concept]  was 
invoked  using  tbe  right  mouse  button  and  specifying  tfaat  tbe  concept  OBJECT  was  to  be  spedaltzed.  Tbe  use  of 
tight  button  exposed  a  set  of  opdoos  on  how  the  objeq  should  be  named  that  included  adding  a  piefix  to  tbe  naire  of 
tbe  parent,  OBJECT.  Clicking  on  tbe  current  editor  object  RED  specifies  that  tbe  name  sbooid  be  RED-OBJECT 
and  tfaat  subsequent  uses  of  the  macro  on  otbercokns,  like  GREEN,  will  create  coocepa  like  GREEN-OBJECT. 

Next,  tbe  COLOR-OF  slot  of  RED-OBJECT  wai  changed  to  RED  by  pointing  at  I  Change  Structure ,  tbe  old 
vaioe  lestdcdon  (A  COLOR),  mid  tbe  concept  RED. 


Steps  in  COLOR-OBJECTS  macro; 


I  Edit  Concept]  RED 
Click  on  I  Define  Maci^ 
ifiakes  Macro  Item  0  a  RED). 

1.  Make  a  new  concept  which  specializes  OBJECT,  named  by  adding  as  prefix  item  O’s  name  {Creates 
RED-OBJECTas  item  l.puts  it  in  the  current  edit  item  window). 

2.  Change  the  COLOR-OF  value  restnctioa  of  item  1  to  item  0  {RED). 

3.  Change  the  ptimitiveiiess  of  item  1  m  No. 

4.  Classify  item  1.  {This  finds  ail  concepts  with  COLOR-OF  slots  restricted  to  RED,  and  makes  them 
specialiiations  (rf  RED-OBJECT.) 

The  remaining  steps  make  these  speaaUzatioo  links  d^ned  links,  and  remove  the  COLOR-OF  slots 
completely. 

5.  Do  on  SPEOAUZATIONS  of  item  1:  Add  item  1  to  the  parents  of  iteradon  item.  {This  makes  each 
red  object  have  defined  parent  RED-OBJECT.) 

6.  Do  on  SFEdAUZATlONS  of  item  1:  Classify  iteration  item. 

7.  Change  the  pnmitiveness  of  item  1  to  Yes. 

8.  Delete  the  COLOR-OF  restiictioa  of  item  1. 

9.  Do  on  ALL  SPECIALIZATIONS  of  item  1:  Delete  the  COLOR-OF  resmcdon  of  iteratioo  item. 

10.  Classify  item  1. 

Figure  B-18:  Changing  RED  to  RED-OBJECT 

Step  3  was  done  by  clicking  on  |  Primitive;  [and  entering  the  new  value  NO.  Step  4  was  simply  the  command 
I  Classify  Concept .  So  that  all  red  objea  classes  could  be  found  and  made  specializations  of  RED-OBJECT. 


The  lemainiog  steps,  required  to  add  defined  parents  to  spedalizadoos  of  RED-OBJECT  and  to  remove  their 
COLOR-OF  restrictioas,  make  use  of  the  KREME  Stnicture  Editor’s  Map  Edit  command.  This  command  is  used 
tt^perfionn  a  single  editing  operation  on  a  set  of  concepts  reiaaed  to  the  one  being  edited  (e.g.,  direct  spedalizaaonr, 
aU  spedaliTarioos,  afastiactioos,  aO  abstncdons).  For  example.  Step  5  was  created  by  the  mouse  sequence 
[Map  Edtt],  ISpedaiizations ,  [MD-OBJECT  lAddStmctnret  the  keyword  |  Abstractions;  of  the  specialization 
that  appeals  temotanly  in  the  edit  window,  and  finally  pouting  to  the  concept  definitiool  RED-OBJECT |. 


B.4.4.1  Running  Macros 

To  mn  the  macro  os  other  objects,  first  edit  the  concept  yon  wish  to  stut  with,  then  click  tight  on 
I  Ron  Macro]  and  selea  [Current  Macro  |  fiom  the  pop-up.  If  yon  want  to  do  the  macro  one  step  at  a  time,  also 
dick  ISingjo  St^  When  you  exit  this  pop-up  menu,  another  will  ^ipear  fiom  you  will  be  asked  to  select  which 
sea  at  rdaitves  of  that  concept  (Spedaiizatioiis,  AU  SpedaUzatioin,  etc.)  you  wish  to  ran  the  macro  on. 


lodiridub  only  «»<■”«  only  apply  ttae  macro  to  concepts  that  are  marked  as  individnals.  Include  current  concept 
asks  if  you  wish  to  run  tfae  macro  only  on  tbe  relatives,  and  not  the  current  corxxpt  itself 

If  you  use  the  single  stepper,  then  you  will  with  the  Macro  Steppcr>,  which  has  the  following 

commands: 

•  Help  -  print  the  list  of  commands, 

•  Execute  the  next  step  in  tbe  macro. 

•  Proceed  with  tfae  rest  of  tbe  steps  without  stopping. 

•  Skip  execution  of  tbe  next  step. 

•  Delete  tfae  current  step  from  tbe  macro. 

•  Insert  a  step  into  tbe  macro  at  this  point  (which  you  specify) 

•  Quit  tfae  macro. 


To  load  previously  saved  macros,  use  tbe  [Load  Macros|  command.  A  pop-up  menu  will  display  tbe  files  that 


contain  saved  macros.  (Tbe  macro  file  fi>r  coloring  objects  is  in  the  file  CXILOR-OBJECT.) 


To  display  a  loaded  macro,  use  the|Display  Macr^co>n*"»nd.  This  command  also  makes  a  loaded  macro  tfae 


cunent  one. 


To  save  a  macro,  use  tbe  iSaveMaq^  command  fiom  tbe  menu  on  tfae  name  of  the  macro  displayed  in  tbe 


macro  definition  window. 


B,5  The  Generalizer 


Experienoed  lowwledge  engineers  are  often  able  to  discover  and  define  useful  generalizations  that  help 
organize  tbe  knowledge  described  by  a  human  domain  expert  Tbe  expert  although  not  previously  aware  of  such  a 
generalizatioo.  will  often  immediately  perceive  its  relevance  to  bis  own  reasoning  processes,  going  so  ^  as  to 
suggest  improvements,  related  generalizatioos,  more  abstract  generalizations  and  so  forth. 


As  an  initial  experiment  in  automatic  generalizatioo  within  ftame  taxonomies,  KR£ME  provides  a  relatively 
sitnpie  generalizer  algorithm  (hat  relies  on  the  user  to  selea  fiom  a  set  of  potential  generalizadons  discovered 
essentially  by  exhaustive  search. 


To  uee  tbe  generalizer,  click  on  [Generali^  in  tbe  main  iiMnu.  KR£M£  will  then  start  a  background 
process^  to  search  fi>r  pairs  ot  larger  sets  of  concepts  that  share  some  number  of  features  (slots,  equivalences. 


I  ia  Cntfar  itow  (Mkio|  iliniT  II  iiiinim  rn  |n  rtrirt|h  amnwckotJOOconeepa  aad300  reha).  itrenaaa  a 
laa  dw  aditor  ia  wiMns  tor  iapM  from  tba  aacr. 
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Figar«B>19:  Sunning  the  macro  COLOR-OBJECT 
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paiems,  etc.)  For  each  such  set  it  finds,  the  geneiaiizer  will  then  form  the  most  specific  concept  definition  that 
encloses  ail  of  the  features  but  is  more  general  than  any  concept  in  the  set  This  concept  definirinn,  a  potential  new 
abstractioa  of  a  number  of  concepts,  will  be  displayed  to  you.  If  you  find  that  the  ger^ralizatioa  is  useful,  ^>ecify  a 
name  when  prompted.  The  newly  named  concept  is  then  clarified  and  insetted  into  the  network. 

To  run  the  Generalizer 

•  ClickoolGeneraliie 

•  The  [Generali^  Command  will  be  higblighted  and  will  remain  highlighted  until  it  a 

geneializatioa  At  that  time  the  |  Generalize!  will  blink  to  alert  you  that  it  has  found  a  generaiizaiioa 

•  Hit  <S1}PER>  <R£FRESH>  to  make  fCREME  show  you  what  it  has  found.  You  will  see  a  menu  of 
choices  prompting  you  to  make  and  clarify  the  concept: 

*  Y  to  reject  the  concept 

*  N  to  defer  making  your  choice  until  yon  have  more  information.  Deferring  will  pop  you  back  to 
the  state  of  the  network  before  you  typed  <SIJPER>  <REFR£SH>. 

*  D  to  form  the  concept  without  lassifying  it  maidng  it  the  top  item  on  the  Edit  stack.  KREME 
will  ask  you  to  give  tte  new  concept  a  name. 

*  E  to  Edit  the  definition  of  the  new  generaiizaiioa 

•  Click  on  <SUPER>  <ABORT>  to  end  geneializatioa 


B.6  The  KREME  Rule  Editor 


B.6.1  Introduction 

In  Expert  Systems,  rules  :ue  ofien  wganized  imo  packets  aixl  the  requirements  for  altering  atsd  inspecting  the 
lelanooshtps  between  rules  have  analogs  in  the  packet  domain  KREME  provides  focilities  to  see  displays  of  the 
relationships  between  packets,  and  to  inspect  the  inteinal  strucrare  of  {nckets  and  titles. 

KREME’s  Rule  Editor  is  equipped  with  a  number  of  features  diaf  farilitat^  building  and  maintaining 
knowledge  bases  of  rales  and  rale  packets.  The  Rule  Editor  uses  the  same  basic  operations  as  the  Macro  Structure 
eduDT  discussed  earlier.  It  cootaios  facilities  for  creating  and  editing  rales  and  rule  packets,  copying  rules,  moving 
them,  compiling  rales  and  displayiiig  and  modifying  variable  bindings.  The  system  provides  an  elementary  history 
and  trading  tnedianLsm,  and  an  explanation  system  that  {soduces  pseudo-English  explanations  feom  rule  traces. 
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Fignn  B-20:  Hodiiig  a  new  geoeializatioa. 
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B.6.2  Editing  Rules  in  the  KREME  Environment 


KREME  at  {nesent  edits  rales  in  the  FLEX  [17]  rale  language.  In  FLEX,  rales  come  in  rule  packets,  and  the 
KREME  Rule  Editor  edits  an  entire  packet  at  one  dme.  Rule  packets  provide  a  way  to  organize  rales. 

The  forwaid  fhaining  niie  packets  come  in  fioor  varieties,  indicating  the  type  of  control  mechanism  used  for 
role  firing. 

•  do-l-mic^ackets  execute  the  first  rale  whose  test  succeeds. 

•  do>alI<nilc-packets  execute  all  rales  whose  tests  succeed. 

•  while-l-mle-packets  repeatedly  test  all  rales,  firing  one.  until  no  tests  succeed. 

•  wiiile-ail-nile-packets  repeatedly  fires  all  rules  whose  rests  succeed,  until  none  succeed. 

Rule  packets  are  connected  to  KREME  fiame  systems  or  other  data  contexts  by  specifying  an  access 
environment.  An  access  environment  is  an  object  that  receives  messages  dealing  with  the  accessing  of  values  for 
references  in  the  roles.  It  hatvtl<^  all  messages  to  get  or  set  the  values  of  variables  and  their  confidences. 


B.6J  The  KREME  Rule  Editor 

Rules  are  defined  and  edited  by  specifying  and  filling  out  p.'itions  of  rule  templates.  To  refine  these  templates 
either  use  the  mouse  to  copy  parts  of  existing  rates  or  point  at  slots  to  be  filled  and  type  in  the  desired  values. 

There  are  also  commands  to  tun  packets  and  debug  them  aird  to  generate  traces  or  rule  histoties  paraphrased 
in  pseudo-English,  and  delete  rales  and  teoider  rales,  and  load  and  save  rules  ftrun  files. 


B.6.4  The  Rule  Editor  View 


Many  of  the  windows  in  the  Role  Editor  View  should  be  familiar  by  now.  The  complete  list  is  as  follows: 

1.  Global  Command  Window  di^lays  global  commands  that  can  be  selected  by  the  user.  In  this 
example,  the  user  has  used  the  mouse  to  select  |Edit  Pad^  The  user’s  selection  is  highlighted. 

2.  State  Window  displays  the  nmne  of  the  packet,  the  network  it  is  associated  with,  and  other  useful 
infinrmatifin 


3.  Editor  Stack  Window  displays  the  names  of  the  items  recently  edited  and  some  infcmnatioa  on  their 
current  state.  Items  in  the  editor  stack  window  can  be  selected  for  editing  with  the  mouse. 

4.  Behavior  Command  Window  is  a  inera  of  commands  that  apply  to  Rules  and  Rule  Packets. 
(Behavior  is  another  term  fim  rale  packets,  or  fimctional  methods  on  instances  of  concepts.) 

5.  Current  Edit  Rem  Window  dis|days  the  item  that  has  been  selected  for  editing. 

6.  Dispay  Rdated  Items  Window  aOows  the  user  to  view  other  rale  packets  and  scroll  through  them. 
Ruin  and  parts  of  rales  can  be  copied  from  (be  Scroll  Window  into  the  Curteot  Edit  Item  Window. 

7.  Editor  Interaction  Window  displays  screen  prompts  and  user  it^Mit.  The  user’s  edits  are  made  in  this 
window  and  then  displayed  in  the  Current  Edit  Item  Window. 
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8.  Related  Behaviors  Window  displays  an  index  of  other  mle  packets  that  are  related  to  the  one 
cnnently  being  edited.  With  the  mouse,  the  user  can  rapidly  scroll  through  this  index  and  selea  a 
leiaed  rule  {mcket  ftv  viewing  or  editing. 

To  get  into  the  Rule  editor  use  tfaejNew  Packet  |  or  (Edit  P«Jtet|  command  in  the  global  command  window. 

Tbereafter,  yon  can  use  thestmcniie  editor  in  much  the  same  way  the  Macro  Stroctuie  Editor  is  used  to  edit 
coocqMs.  The  Rule  Stmctnrc  Command  Menu  contains  the  commands: 

•  I  Define  Behaviorl  is  similar  to  I  ClassiiyConceptl  It  makes  the  definition  of  the  packet  permanent,  and 
aflows  it  to  be  ran  or  attached  to  a  concept 

•  ISimilar  Behaviorl  -  Creates  a  packet  with  the  same  rules,  etc.  but  gives  it  a  new  name,  aixl  presents  it 
to  be  edited  to  make  it  different 

•IKill  Behavior  -  Kills  the  definition  of  this  packet 

•  IDisplay  Packet|-  Displays  the  packet  in  the  Display  of  Related  Items  Window. 

When  a  whole  rale  packet  is  outlined  (such  as  when  you  are  over  the  word  Packet),  you  can  choose  to 
[Edit  Packet]  (L;),  or  (R:)  choose  from  a  menu  of  [Edit  Packet  j  [Edit  Basis  |  or  |  Display  Lisp  Form]. 

Other  editing  commands  are  found  on  the  keywords  and  component  pieces  of  packets  and  rules.  For  instance, 
clicking  left  on  |Rule^  places  a  new  (empty)  rule  in  the  packet  which  can  then  be  filled  out  by  clicking  on  to 
add  a  new  conditioo  (conditioos  are  treated  as  part  of  a  conjunction)  or  | THEN]  to  add  a  t»w  action.  CTlicking  right 
gives  a  menu  of  [Add  (Empty  Rule),  [Copy  One  Rule  from  scmewhete  else  into  this  packet  and  [Copy  Rule  Set| 
which  copies  all  of  the  rales  from  another  packet 

Clicking  over|Typ«  gives  you  a  choice  of  the  standard  types  of  rale  packets,  described  above. 


[Packet  gasses;!  allows  you  to  specify  a  fiavor  to  be  mixed  into  the  packet  jArgumentsTj  and 
I  Return  Variables;  each  allow  you  to  add  a  new  one  (L;)  or  choose  from  a  mean  of  |  Add  One  ,  [Add  Several!, 


When  a  whole  rale  is  outlined,  clicking  left  will  be  replace  the  rule  with  another  rule  that  you  point  at. 
Oiddng  tight  gives  a  menu  of|  Replace  Rule  j  |  Edit  Attributes!  and  [Delete  Rulej. 


Whenever  espressioos  appear  (after  the  word  Precondition;,  or  as  parts  of  coodihons  or  actions),  the  user 
may  [Replace!  the  expression  (L:),  or  choosing  from  a  menu  (R:)  of 

•IRepiacejtfaeexpiessioa  with  .mother  one. 

•[EdBtltbeexpiessiooastexL 

•[Ddetel  the  expression. 


•j  Add  B«lbre|  anotber  e:qne3sion  (copied  from  somewbere  by  ptMiibng). 

•  aootber  expressioa 
•iKwhenjeltwoexpiessiooi  poaiiioiM. 
•IPireadieaiMlaaetofaqgesaoostogetber. 

•IPepareatfaeaixel  an  ctpreaaoo  into  pieces. 

•  I  ETntaurt^tbeejqnession  in  tbeconeot  context. 
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